In this Help Net Security video above, Erik Costlow, Senior Director of Product Management at Azul, talks about Java centric vulnerabilities and the headache they have become for developers everywhere.
He touches on the need for putting security back into DevOps and how developers can better navigate vulnerabilities that are taking up all of their efforts and keeping them from being able to focus on the task at hand.
Just over a year ago, we wrote about a âcybersecurity researcherâ who posted almost 4000 pointlessly poisoned Python packages to the popular repository PyPI.
This person went by the curious nickname of Remind Supply Chain Risks, and the packages had project names that were generally similar to well-known projects, presumably in the hope that some of them would get installed by mistake, thanks to users using slightly incorrect search terms or making minor typing mistakes when typing in PyPI URLs.
These pointless packages werenât overtly malicious, but they did call home to a server hosted in Japan, presumably so that the perpetrator could collect statistics on this âexperimentâ and write it up while pretending it counted as science.
A month after that, we wrote about a PhD student (who should have known better) and their supervisor (who is apparently an Assistant Professor of Computer Science at a US university, and very definitely should have known better) who went out of their way to introduce numerous apparently legitimate but not-strictly-needed patches into the Linux kernel.
They called these patches hypocrite commits, and the idea was to show that two peculiar patches submitted at different times could, in theory, be combined later on to introduce a security hole, effectively each contributing a sort of âhalf-vulnerabilityâ that wouldnât be spotted as a bug on its own.
As you can imagine, the Linux kernel team did not take kindly to being experimented on in this way without permission, not least because they were faced with cleaning up the mess:
Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way. This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your universityâŠ
Developers Remediate Less Than a Third of Vulnerabilities
Developers are regularly ignoring security issues as they deal with an onslaught of issues from security teams, even as they are expected to release software more frequently and faster than ever before.
In addition, developers fix just 32% of known vulnerabilities, and 42% of developers push vulnerable code once per month, according to Tromzoâs Voice of the Modern Developer Report.
The report, based on a survey of more than 400 U.S.-based developers who work at organizations where they currently have CI/CD tools in place, also found a third of respondents think developers and security are siloed.
Tromzo CTO and co-founder Harshit Chitalia pointed out the top security vulnerabilities of the past few yearsâLog4j, SolarWinds, Codecovâhave all been supply chain attacks.
âThis has made AppSec an urgent and top priority for CISOs worldwide,â he said. âIn addition, everything as code with Kubernetes, Terraform and so on have made all parts of the development stack part of AppSec.â
From his perspective, the only way this big attack surface can be overcome is with security and development teams working hand in hand to secure the application in every step of the development cycle.
He added developers ignoring security issues is one of the fundamental issues AppSec engineers have with security.
âSecurity teams put their blood, sweat and tears into finding different vulnerabilities in code through orchestrating scanners and manual testing,â he said. âAfter all the work, seeing the issue on Jira queue for months is disappointing and quite frustrating.â
Fighting Friction
On the other hand, he pointed to developers who are now asked not only to develop features and fix bugs but also look at DevOps, performance and security of their applications.
âThis leads to friction in priorities and, if unresolved, leads to unhappy employees,â he said. âThe C-suite is very much aware of this problem, but they are stuck with security tools which are not created for developers. As application security is going through a big transformation, we believe the tooling will also shift.â
He explained there were several concerning findings from the survey but that two, in particular, stood out.
The first thing Chitalia found deeply concerning was the fact that 62% of developers are using 11 or more application security tools.
He said application security has evolved in recent years with AppSec teams now responsible for source-code analysis, DAST, bug bounty, dependency, secrets scanning, cloud scanning and language-specific scanners.
âThis means developers are constantly fed information from these tools without any context and they have to triage and prioritize the workload these tools generate for them,â he said.
The second big worry was the fact that a third of vulnerabilities are noise.
âIf someone told you that a third of the work you did needs to be thrown away every single day, how would you feel about that?â he asked. âBut thatâs the current state of application security.â
You can only get rid of WAF if you fully implement security into your development process and audit the process via code reviews and annual tests. But DevSecOps canât be realistically implemented for all web apps in the enterprise environment, so WAF will stick around because it still has a job to do.
The WAF is not dead, whatâs left?
DevOps and the continuous integration and continuous deployment (CI/CD) pipeline provide an excellent opportunity to implement security, especially if your agile methodology includes security sprints. It allows for security to be built into the apps from the start, rather than taking the traditional route of applying it later, which is not only inefficient but â in the frenetic pace of CI/CD â can be overlooked, ignored, or forgotten.
Although security for all web apps should be built-in from the start, our experience shows that it is usually only applied to the âcrown jewels,â like the companyâs primary customer portal or client payment systems. In an enterprise environment, itâs not unusual for a company to be running old apps in which code is no longer maintained or apps integrated through acquisition.
Additionally, departments such as R&D and marketing frequently implement custom or third-party applications. This app proliferation can result in more than 50% of public-facing web applications in an organization being managed by DevOps or other disparate IT groups. These apps will need additional mitigation controls, which is where WAF comes in.
A research from Secure Code Warrior has revealed an attitudinal shift in the software development industry, with organizations bucking traditional practices for DevOps and Secure DevOps.
The global survey of professional developers and their managers found 70% of organizations recognize the importance of secure coding practices, with results indicating an industry-wide shift from reaction to prevention is underway.
Dr. Matias Madou, CTO at Secure Code Warrior, said, âWe are seeing a fundamental shift in mindsets across the world, as the industry slowly moves from reactive, band-aid solutions rolled out after a breach, to the proactive and human-led practice of writing quality software that is intrinsically free from vulnerabilities right from the very first keystroke.â
âThis research shows that âsecure codeâ is becoming synonymous with âquality codeâ within software development, and security is becoming the responsibility of development teams and leadersânot just AppSec professionals,â he said.
Secure coding practices
Reactive practices like using tools on deployed applications and manually reviewing code for vulnerabilities were the top two practices respondents associated with coding securely.
However, a proactive shift in mindset was evidenced across the globe, with 55% of the developers surveyed also recognising secure coding as the active, ongoing practice of writing software protected from vulnerabilities.
