The term ‘software supply chain security’ (SSC) can be interpreted in many ways. Following the White House executive order in May 2021 and the European Cyber Resilience Act (CRA) of 2022, both governments and corporations are taking a more active role in ensuring their software is secure. Fundamentals such as having a software bill of materials (SBOM) and being able to cross-reference it with known common vulnerabilities and exposures (CVEs) are now the standard, but supply chain security covers far more than just the software that builds your products.
To create certainty and clarity, leading standardization bodies such as OWASP, OpenSSF and others have set up ongoing efforts to define and mitigate SSC threats. They have active working groups, SIGs and TACs all working in vendor-neutral ways to help define and solve parts of the SSC problem.
A great example of this is the continuous work being done by Google Cloud’s DevOps Research and Assessment (DORA) initiative. More specifically, the subject was reflected in the September 2022 DORA report that focused on security in general and supply chain security in particular. Using the Supply-chain Levels for Secure Artifacts (SLSA) framework as well as the NIST’s Secure Software Development Framework (SSDF) as benchmarks for actively addressing supply chain security issues, the researchers assessed how organizations were successful in approaching and addressing threats at all levels of the organization.
My view of the major findings of the DORA report are summarized below.
Who Owns Software Supply Chain Security?
The report stated that organizations should empower individual teams and developers to “own” security while administering a consistent security policy and posture across its products. While I agree with this, we need to examine both sides of the ‘ownership’ coin. By nature, this hybrid approach creates complexity—and even friction—between the security team that, by definition, is responsible for all facets of security and the developers that are being tasked to ‘fix’ security issues in addition to their daily tasks. There has to be common ground between developers, their tasks associated with security and the security team.
Individuals in organizations that build software care about what they build; they have a stake in the overall success of the final product and this feeling of ownership strengthens that level of care. However, asking for such ownership while adding a security component to the mix without providing sufficient knowledge, tools, proofs, and “power” to make decisions could lead to a lack of trust, confusion, execution problems and frustration. To alleviate this, the security team should provide developers the tools, education and resources they need to feel empowered to enhance security efforts at the source. Organizations that provide evidence in a scalable, digestible manner are successful in building trust and creating common ground between the developer, security and the security team.
There’s also another dimension that could potentially create silos between developers and security teams rather than bringing the two together: There’s no one single security team or owner of SSC. SSC is tricky to define as a category; it involves shift left security, runtime security and everything in between. Some portions of it are being governed by the security office, some by AppSec, some by DevOps and some by the developer. The ownership of each isn’t well-defined and the entire effort is very difficult to consolidate as one process or methodology. In addition to upskilling the developer with tools and training, long-term education, thought leadership and access to good technology are the keys to gradually reduce these friction points..
Security Processes Slow Down Development
Defining the tools, methodologies and processes that should be employed in an organization to add sufficient security while not impacting development speed is not a trivial task.
The following are four principals I think correspond well with the SLSA framework and that help address the development slowdown challenge:
Set preventive measures: Avoid using known vulnerable and malicious packages from the beginning of development. By eliminating vulnerabilities introduced in first-party code (due to bad coding practices) as well as misconfigurations, wrong encryption and secrets exposures, you are preventing known threats from entering your product.
Examine proactively and continuously: The security state of software changes because the software itself always evolves and new vulnerabilities are continuously being introduced. It makes a software artifact that was just secured suddenly become susceptible to attack. This requires continuously rescanning and revisiting software artifacts as well as frequently recalculating any potential risk.
Set preemptive measures: Create a plan that initiates a prompt response when a potential risk is discovered. Both development and security teams should create the plan for decision making and execution. The measures should include ways to identify vulnerable artifacts across development and production, how to understand exploitability and true impact and how to prioritize and remediate accordingly.
Do it all in an automated manner: Create automated processes based on reliable data and scanning tools to dramatically reduce the effort needed by developers and DevOps teams.
DORA report co-author Eric Maxwell said one of the main principles is to remain tool- and platform-agnostic while focusing on capabilities and practices. From that perspective, automation is essential and it is enabled by security-as-code. Having a common language–code–allows teams to communicate about security as well as collaborate. It drives the things we discussed earlier around democratizing the security process and helps break down silos.
The DORA findings—alongside the topics described above—encourage community awareness and continued shared efforts to bring much-needed attention to software supply chain security. Gradually, SSC security will evolve, but as it does so, the only way to properly address it is by ensuring the developers and security teams are on the same page and both have ownership of responding to and resolving issues as they appear. For more in depth review of the DORA report I encourage you to view Leap Left for Security: The DORA Report Roundtable.
