Here’s something you probably already know: applications these days are largely created using open source components. In fact, Debricked estimates about 98% of all code bases rely on open source libraries to accelerate the development process!
In my previous blog on software supply chain security, I wrote about software pedigree—do we really have an understanding of our software’s lineage and the inherent risks of the software we are introducing to our enterprises? Maybe not.
Fortunately, Fortify has resources available to help you secure your software supply chain. We recently sponsored a webinar with Debricked and Dark Reading titled Shoring Up the Software Supply Chain Across Enterprise Applications. Did you miss it? If so, don’t worry, I’ve got you covered with a recap below. You can also view the full webinar on-demand here.
Modern-day software development depends heavily on third-party components, libraries, and frameworks. Attackers are increasingly targeting these software building blocks to compromise enterprise applications. The ever-expanding software attack surface requires a new approach to identifying and remediating vulnerabilities before writing code.
Fortify’s Debricked solution uses machine learning algorithms to identify existing and potential security vulnerabilities based on enterprise-specific policies. The tool also enables automated remediation for a more secure software supply chain.
“Either you investigate, find what's the root cause, and remediate it or somebody else will investigate, find the root cause, and exploit it. The choice is up to you.”
- Jonathan Care, Independent Cybersecurity Expert
The software supply chain is complex, with many layers of vulnerabilities.
The software supply chain is anything that produces software used in the enterprise application stack. Supply chain software can come from third-party consultants, contractors, or external vendors (who may be leveraging their own third-party consultant or external vendor software). Software includes everything from open-source components; to tooling such as CI/CD, testing, and source code control; to the infrastructure used to develop and deliver software products.
An enterprise might play the role of both customer and supplier—whether to end users or other companies—in the software supply chain. As a customer of upstream software, the business might include third-party components in addition to in-house developed code that, in turn, is supplied to downstream consumers. The ripple effect of an exploited vulnerability can be significant.
The depth and breadth of software used in the enterprise application stack makes software supply chains complex, with hundreds or thousands of components involving multiple teams and third parties. As a result, software supply chain security must be integral, requiring visibility, clear policies, and continuous improvement.
“[Security] is not a ‘set it and forget it’ game that we're about to engage in.”
- Jonathan Care, Independent Cybersecurity Expert
There is enormous potential for vulnerabilities in the software supply chain. Common vulnerabilities include:
- Stolen certificates. Identity protection remains an important mainstay of enterprise security posture in the cloud.
- Compromised software development tools or infrastructure. Examples include unauthorized insertions into source code repositories and compromised content delivery networks.
- Preinstalled malware on devices. Manufacturer OEM images or firmware sometimes contains surprising things!
- Malicious code in components’ firmware. Looking into device drivers and firmware can reveal vulnerabilities.
Software vulnerabilities are the most likely entry point for supply chain attacks.
ENISA, the European Union Agency for Cybersecurity, looked at supply chain attacks in 2020 and into the start of 2021. ENISA found that out of the known attack techniques, the most common one was exploiting software vulnerabilities, with 66% of targeted assets focused on suppliers’ code (as opposed to data or processes).
A rapid increase in the number of known vulnerabilities has occurred because:
- Security has received much more attention due to attacks. Some enterprises put bug bounty programs in place to incentivize finds.
- Centralizing vulnerability information has greatly improved, making it much easier to report new vulnerabilities.
- Attacks themselves are more lucrative, creating an incentive for bad actors to find vulnerabilities to receive monetary rewards for launching an attack.
- Enterprises and society as a whole are much more reliant on software than in previous years. That software is also used for more critical services, including protecting sensitive data and privacy.
- Martin Hell, Security Strategist at Debricked, OpenText
Known vulnerabilities in the National Vulnerability Database, 1999 to 2022
The trend demonstrates that there are still unknown vulnerabilities in components, but with so much code and a high number of components, manual review is extremely difficult and error prone. Automation is key to securing the software supply chain and to finding and fixing vulnerabilities quickly and efficiently.
Proactive, continuous improvement is critical to securing the software supply chain.
CISOs might be aware of the concept “shift left of the boom.” Meaning, to apply corrective measures as early in the development and implementation process as possible. Application security is a relatively new discipline and understanding how to secure the software supply chain can be a challenge.
The application security program should functionalize business requirements and meet deadlines as part of their operations; it should also “shift left” by putting controls in the CI/CD, development, and testing, and/or DevOps processes, including:
- Implement automated vulnerability scanning. Leverage tools that allow scanning of operational and test environments to find vulnerabilities in deployed code. SAST (static scanning) and DAST (dynamic scanning) can be used to test source code both in development and in deployment.
- Check transitive dependencies. Identify and secure risks. For example, a buffer overflow is a very common vulnerability, allowing attackers to run with elevated privilege.
- Validate the source. Source code should be checked for anything that can expose the enterprise to risk.
- Chip away at security debt. Make continuous scan and update part of the workflow.
- Don’t wait for vulnerabilities to be exploited.
An executive order from the Biden administration requires vendors to the U.S. government to buy skilled development supply chain practices. However, for vendors supplying the private sector, there is no legal mandate to enforce these policies, creating a challenge for enterprise CISOs.
Making developers more aware of the security impact of their work can improve security. Automated vulnerability scanning and source validation will help to shift left—checking for source code flaws as early as possible in the IDE and the automated pipeline, and failing builds that do not pass a security policy and preventing pull requests for code that fails SAST prevents problems later on.
Tactics for software supply chain security: Winning hearts and minds to ensure success.
The SBOM is a software bill of materials—a comprehensive list of every component used to build an application. SBOMs play an important role in untangling the complexity of software supply chains and software ecosystems.
In an ideal world, vendors would be required to provide provenance before code can be accepted. However, it can be difficult for them to provide a comprehensive SBOM, which makes a proactive and holistic approach to application security even more important, especially in an agile environment.
Application security cannot be top-down; rather, the most successful security approach is a collaborative one. Issuing decrees without buy-in, or saying no to functionality, often leads to ignored guidance or unauthorized workarounds, which in turn increase risk of a breach.
CISOs who step back from a gatekeeping stance and focus on enabling developers and other teams to shift left are less likely to be seen as a blocker. A more effective way to build application security practices is to be a source of knowledge and help. This can be accomplished by:
- Creating standards for application security and communicating them. Talk to developers and explain why and what is needed for security. Explain what secure development means.
- Providing courses for secure coding and incentives for developers that go above and beyond. Give people the tools and capabilities they need to do the job, and reward those who excel.
- Making friends with project managers and briefing them on security requirements so they know to reach out to you when new projects spin up. Educate colleagues about how security ultimately can delay, impact, or even derail deliverables on which they are measured.
“We must roll up our sleeves and get ourselves into the software supply chain, into the delivery chain, into the development chain. How can we help? How can we inject security testing? How can we be active and present in that process?”
- Jonathan Care, Independent Cybersecurity Expert
Take full control of open source security with solutions that will revolutionize the way you use open source with Debricked Software Composition Analysis.
More About Fortify
Fortify delivers software resilience for modern development with a holistic, inclusive, and extensible application security platform from a trusted partner that supports today’s enterprises. This comprehensive suite of products brings holistic security and visibility to developers, AppSec professionals and key stakeholders with automated integrations for any tool, anywhere in the SDLC and a robust set of capabilities available on premise, cloud-hosted, or as a managed service.
Join our Fortify Community. Have technical questions about Application Security products? Visit the Fortify discussion forum. Keep up with the latest Tips & Info about Application Security. We’d love to hear your thoughts on this blog. Log in or register to comment below.