July 26, 20230 mins read
AI, false positives, and slow security tool adoption remain concerns but faster fixes and supply chain security progress are encouraging signs.
The 2021 Log4Shell incident cast a bright light on open source software security — and especially on supply chain security. The 18 months following the incident brought a greater focus on open source software security than at any time in history. Organizations like the OpenSSF, AlphaOmega, and large technology companies are putting considerable resources towards tooling and education. But is open source software security actually improving? And where are efforts still falling short?
Snyk set out to answer this question in our latest report, the 2023 State of Open Source Security. We surveyed hundreds of technical folks and analyzed anonymized data from our product suite’s real-world usage to collect these results. This report aims to shed light on supply chain security's current and future state, giving organizations a way forward as the software supply chain industry grows. Here are a few of our biggest findings.
Supply chain security isn’t keeping up with development
As open source development tooling continues to grow and draw the attention of malicious actors, companies must consider adopting supply chain security approaches.
Automation and AI create new opportunities and challenges
The rise of automation and AI are clearly impacting application development. We see great strides in using these technologies for security. But are these emerging technologies helping or harming security postures?
According to our report, there’s still hesitation behind these new technologies, with mixed opinions of whether or not AI tools will improve code security. We also see mixed results in the effectiveness of security automation — 61% of respondents said that automation has increased their false positives.
Despite these varied opinions, most organizations continue to lean into these new technologies for development and security. Only time will tell how AI and automation affect their software supply chain security.
Supply chain security hasn’t shifted left yet
A key tenet of supply chain security is empowering developers to spot vulnerabilities earlier in the software development lifecycle (SDLC). This means giving developers the tools and training to code more securely and scan more frequently. These practices improve speed and efficiency in the SDLC as fewer builds are blocked in pre-deployment testing and routed back to developers to fix.
Our survey found that shifting left also remains unfinished business. Only 40% of respondents indicated that their organization deploys security tooling into developer IDEs, with an even smaller percentage using them locally on the command line. Build tools and code repositories are the most common locations for security tools — both around 65%. This statistic shows that teams are still putting supply chain security tooling later in the development stage as part of build or code check-in processes rather than as a continuous approach to code security.
To fully realize the vision of proactively shifting left, developers need to have access to the same security tooling as DevOps, application security, and other downstream teams. While 40% is not a bad number, it means security tooling in the developer’s most important workflow tools remains in the minority.
False positives from automation are unacceptably high
Many organizations have deployed automated security measures in the code pipeline. That has resulted in an increase in false positives in vulnerability warnings, potentially hindering productivity. In the survey, 64% of organizations have automated code analysis, 61% have automated software update management, 59% have automated testing (unit, security), and 58% have automated secure coding practices (linters, formatting, etc.). While making it easier to scan for vulnerabilities, automated security tooling has also increased the rate of false positives. 60% of respondents stated automation had increased false positives, versus 30% saying automation had decreased false positives. As a percentage of alerts, false positives represented a considerable share, with 62% of respondents stating that 25% or more of vulnerability alerts they received were false positives. 35% of respondents reported that 50% or more of their alerts were false positives.
This high percentage of false positives creates a huge technical overhead for security and development teams and potentially undermines the benefits of automation. Teams will need to focus on ways to reduce false positives to truly improve software supply chain security.
There are pros and cons to increased security response
Several high-profile attacks have caused an increased focus on supply chain security. Engineering and security teams are also facing pressure from governmental bodies, such as the United States Executive Order on Improving the Nation’s Cybersecurity and the EU’s pending Cyber Resilience Act.
Because of these factors, several respondents have recently kicked into high gear with their security practices. A few of these initiatives included new tooling, increased code scan frequency, and training.
But despite a federal software bill of materials (SBOM) mandate in 2021, only 42% of organizations use an SBOM. And those who do face a “Tower of Babel” situation with their SBOMs. Our report uncovered that organizations use several different software development, CI/CD, and supply chain security tools to generate SBOMs. As a result, today’s SBOMs are varied and may lack interoperability, making it difficult to analyze them meaningfully. So while many organizations are “checking off the SBOM box,” they still aren’t leveraging them to their full potential.
While supply chain security is improving, it still needs work
Overall, the 2023 State of Software Supply Chain Security Report shows that while software supply chain security is improving, it still needs work. As a sign that we’re headed in the right direction, our research showed an improvement in time to fix (TTF) across all severity levels and most major open source ecosystems. In fact, the TTF of open source components is currently outpacing fixes in proprietary software. There are a few possible explanations for these positive trends, like wider adoption of open source security tooling such as SCA, more funding and personnel dedicated towards fixing critical open source vulnerabilities, greater security awareness in open source projects, etc.
Our findings also indicated that we’re in a transitional period — moving from older approaches to newer methods and technologies. All in all, this means that we’re on the right track, but we must keep moving forward and innovating to reduce open source risk in the future.