Software security has been an important concern for organizations for a long time now. However, with the growing complexity of modern software supply chains, it has become increasingly difficult to keep up with the rapidly evolving threat landscape. To address these challenges, there’s been a shift in responsibility when it comes to security vulnerability remediation—a shift left to the developers.
In this blog post, we will:
- Review the limitations of today’s DevSecOps practices.
- Explore emerging trends in application security (AppSec) that you should know about to better protect your software.
- Answer the question: Should the security of your codebase be the responsibility of individual developers?
Scanning the software supply chain does not mean it’s secure
The software supply chain has become a key component of modern software development practices, with as much as 90% of code coming from third-party components. While this allows for faster application development, it also increases the complexity of software maintenance, as third-party dependencies change and evolve at their own pace.
Additionally, these composed applications have a larger attack surface, making them at higher risk to software vulnerabilities that are on the rise, surpassing 25,000 in 2022. Case in point, one audit of 1,250 commercial codebases revealed that 75% of the codebases contained open source components with known security vulnerabilities.
As a response, security has been shifting left in the context of DevSecOps practices, and developers have become more responsible for addressing security vulnerabilities in this increasingly complex codebase.
Code search and scanning solutions, particularly static application security testing (SAST), software composition analysis (SCA), and security vulnerability scanning, are in more use than ever to try and help keep vulnerabilities at bay. In fact, one study shows us that 90% of applications are scanned more than once a week and that there has been a 31% increase in the full suite of scanning tools.
Typically, it’s the newly developed or changed code that is actively scanned and actively, manually remediated by developers when vulnerabilities are found. These application security tools act as gates that block errant code from shipping to production, which requires developers to respond.
While this can keep new or modified code clean of vulnerabilities, it does not help existing, unchanged code. Recent developer data indicates that almost 50% of developers knowingly ship vulnerabilities in their code (and this is not a secret!).
Yes, we as an industry accept a large surface of vulnerabilities in our existing software as status quo, as it’s more important to ship new features than to fix older code. At the end of the day, only the most critical defects in the most critical applications may be getting remediated.
New U.S. government policy is leading the way to changing this dynamic. It’s no longer okay to pass vulnerabilities along to end users. According to the latest National Cybersecurity Strategy issued by the White House, “This strategy recognizes that robust collaboration, particularly between the public and private sectors, is essential to securing cyberspace. It also takes on the systemic challenge that too much of the responsibility for cybersecurity has fallen on individual users and small organizations.” We all must work to defend the critical infrastructure of our society.
Limitations of DevSecOps, SBOMs, and manual remediation
How does software defense work in practice today? Software supply chains are constantly shifting and new vulnerabilities can be introduced by anyone at any time. Code that is considered clean now becomes vulnerable when a new vulnerability is discovered. Basically, that vulnerability lurking in the code in some transitive dependency could be the weak link that is exploited next, creating real business risk. Today’s practices of vulnerability remediation are helpful but all have limitations for managing a constantly evolving codebase.
Secure today, vulnerable tomorrow
The intent of DevSecOps and associated security testing solutions has been to ensure that security becomes part of the development process with the aim to reduce the number of vulnerabilities that may be introduced during development. Running a DevSecOps practice is not enough because not all software is built all the time. Even when applications are not actively worked on by developers, they still need to be remediated because what is considered secure today may be vulnerable tomorrow.
Dependency complexity hides flaws
Using the software bills of materials (SBOMs) and associated scanning solutions to understand what software in production is vulnerable is not enough. While the visibility can lead to manual remediation, especially for high-risk common exposures and vulnerabilities (CVEs), this visibility might not afford the protection you think.
Consider Solarwinds, and the attack in the CI system that inserted code into an application as it was being built. This was not revealed in the list of libraries nor found in the source code. When a new vulnerability is discovered in a widely used framework, it’s usually specific to a particular use case, such as an API call. How would you know if your application uses this call and therefore is affected? You need a detailed understanding of the application code and all its dependencies to make more informed decisions.
Manual remediation takes too much time
And maybe most importantly, relying on the “all hands on deck” manual response to a new CVE is not enough—it’s not scalable or sustainable. When a CVE is discovered, organizations scramble to understand the level of application security risk and their exposure. Development teams drop other current work to address the apps most at risk. A new CVE can represent unplanned, time-consuming, repetitive work for the development team. The impact analysis required to determine the specific parts of code that are vulnerable can be challenging and the remediation process can be draining to engineers.
For example, an insurance company had to prioritize a Spring Boot version upgrade to secure their code from Spring4Shell, a critical vulnerability in the Spring Framework. This project required a developer per each affected repository who was the ‘migration expert’ for the update to help the teams navigate the way. This was someone familiar with the current Spring Boot version and knowledgeable about the steps needed to upgrade to the secure version.
Just to illustrate the complexity of this one example, the patch of Spring4Shell was included in Spring Framework 5.3.18 and 5.2.20, which required bumping to Spring Boot 2.5.12 (minimally). For this organization on Spring Boot 2.3 and 2.4, this also required updating JUnit 4 to 5, which required updating Mockito 1 to 3. This work was all consuming for the development team and reduced their business output significantly for the quarter.
Whether it’s responding to application vulnerabilities found in real-time on actively worked code or responding to vulnerability surprises that can create “all hands on deck” situations, AppSec whack-a-mole needs to stop.
Removing the “shift-left” security burden from developers with auto-remediation
Rather than shifting the burden of security remediation “left” onto every developer, a new security best practice is to automate and distribute that remediation. Auto-remediation of code goes well beyond finding the vulnerabilities to actually fixing the source code—whether the code is actively worked on or not.
Moderne is an automated code remediation platform for making changes to source code in real-time across 1000s of repositories. The Moderne platform achieves this using the innovative Lossless Semantic Tree (LST), a technology leap from the common Abstract Syntax Tree, to deliver the full fidelity of codebase knowledge required for accurate, automated code fixes. The semantic-based data of the LST is characterized by type attribution, format preservation, and other metadata important in analyzing and manipulating code at scale.
The platform runs open source transformation recipes, which are actual programs, to automate remediation of source code. Recipes operate on the LST, visiting and transforming different parts of the tree. Moderne works within your software development lifecycle to coordinate changes across repositories fast. It then prints the LST back as text for developers to review and accept changes—enabling you to eradicate vulnerabilities quickly.
The beauty is that developers only need to review and oversee this process. Just one developer on a team can manage the auto-remediation workload in a fraction of the time it takes a whole team to manually remediate today. That means the team can focus on adding business value, while the software is in an always-updated state with the latest security patches and upgrades.
Enterprise companies are using Moderne today to improve their security posture through regular upgrades of software stacks and comprehensive vulnerability remediation across their codebase.
Should developers be responsible for AppSec?
The answer is yes and no.
Should developers follow AppSec best practices when creating and testing code? Yes.
Should developers be responsible for securing existing code—such as code they may not have created and code that is largely glue for assembled third-party components? Even for the most vigilant development teams, this is an impossible task. There are too many dependencies, too many repositories, too many vulnerabilities. Manual developer labor cannot keep up. Search and scanning solutions only automate reporting, and can even create noise with false positives.
Think of SBOMs as a first-generation attempt at gaining visibility of the vast software supply chain made up of third-party software dependencies, language runtimes, frameworks, etc. And scanning tools are a first-generation solution stretching their ability to identify security issues in today’s modern applications. The security industry as a whole must move past reporting.
Auto-remediation of code is an emerging solution that can help organizations keep their software up-to-date with the latest patches and updates, without the need for manual intervention from developers. By implementing this approach, organizations can reduce their risk of vulnerabilities and ensure that their software is always secure.
This approach also keeps the responsibility for how to repair the code in the hands of the experts: third-party code maintainers and security researchers. The maintainers and researchers can provide recipes that simultaneously identify the weaknesses in the code and patch them for developers. Instead of 100 developers researching and fixing the same problem, one researcher can write a recipe to fix the problem, and it’s distributed across 100 repositories automatically. By removing the repetitive and time-consuming burden of vulnerability remediation from your developers, they can focus on what they do best—building great software for your business and customers.
For more information, check out this report from IDC on The Compelling Need for Automated, Continuous Code Remediation.
You can also try out auto-remediation for free on open source code or contact Moderne for a demo.
