Securing the Supply Chain
Authors: steve foretHow Far Can We Integrate Security into Software Development
“We calculated a supply chain interconnection influence in 15% of the breaches we saw…For a breach to be a part of the supply chain interconnection metric, it will have taken place because either a business partner was the vector of entry for the breach…or if the data compromise happened in a third-party data processor or custodian site…Less frequently found in our dataset, but also included, are physical breaches in a partner company facility or even partner vehicles hijacked to gain entry to an organization’s facilities.”
Verizon 2024 DBIR
Over the years, I've had the privilege of supporting numerous leadership teams across major brands in cybersecurity, technology, audit, and business sectors. My work has involved organizing, enabling, and enhancing security outcomes related to business applications, ODM/OEM products, and startup solutions. Throughout this journey, I've observed significant variations in how enterprise organizations structure their cybersecurity, software development, technology operations, and how these capabilities support business objectives. Despite these differences, one common challenge stands out: effectively integrating security into software development practices.
The Complexity of Operating a Security Lifecycle
Operating a security lifecycle for products and applications is not an easy task. Many organizations are unaware of just how deeply security can and should be embedded in their business software development practices. As a result, many are not doing enough to secure their product and application lifecycles. What constitutes “enough” varies depending on several factors, including the type of product (IoT, web application, car, phone, etc.), organizational structure, and the ability to integrate and accelerate security checks throughout the development process.
A fully-integrated DevSecOps approach can stabilize developed products by embedding security into every stage of the development process. However, this integration is often limited to specific applications or products that follow the DevSecOps cadence. Products outside of this scope are left vulnerable, relying on the best efforts of the development teams. The importance of this issue becomes glaringly apparent when considering the numerous software breaches over the years, such as the Apache Struts 2 Framework at Equifax.
Where Do I Begin? Key Strategic Questions for Executives
In all instances, it's crucial to ask the right strategic questions to determine if your organization is well-structured for effective security integration:
Ownership and Leadership: Who owns the operating technology that supports business revenue? How many leaders are there? The organization should be structured for consistency and empowerment.
Lifecycle Management: Is there a common definition for the expected life of a business, application, or technology? For example, some organizations mandate that applications must be rebuilt every five years to avoid accumulating software debt.
Breach Preparedness: What is the estimated reserve for costs to remediate a breach? How many major breach remediation events are anticipated during the post-deployment maintenance lifecycle? Proper planning and funding are essential for effective breach response.
Security Posture and Controls: For each product lifecycle, is there a defined baseline control structure and posture checks in design, deployment, and release? Consistent and secure building practices are key to success.
Incident Response Capability: Can you certify or assure your security controls within 48 hours, if necessary, in response to a breach investigation? Rapid response capabilities are vital for protecting revenue streams.
Supply Chain Security: Who in the organization maintains the supply chain list? To what formal capacity do you track and verify third-party software, developers, and open-source software? How is this incorporated into business services? Being prepared for supply chain attacks is critical for organizational security.
Securing the Supply Chain Lifecycle
Securing your application and corporate supply chain is so critical that entirely new standards have been created, such as Software Bill of Materials (SBOM) requirements. These efforts aim to expose sub-components in software that may impact the security of purchased or open-source software. All this is due to the increasing complexity and interconnectedness of modern technology and software development. Application supply chain includes all components, such as code, libraries, and tools, that contribute to the final product. With the widespread use of third-party and open-source software, third party connections, and more, vulnerabilities can arise in any part of the supply chain, ultimately compromising the entire solution or application. For more information on government defined guidance, see this link from CISA.
Common Vulnerabilities in the Supply Chain
There are plenty of conditions and examples, but we wanted to include some of the typical factors driving these vulnerabilities:
Third-Party and Open-Source Software Integration: Integrating a third-party or open-source software component, such as Log4j, into applications can introduce significant vulnerabilities. This specific component was exploited by attackers to gain unauthorized access or execute malicious code (at one point was up to 35,00 java package has this insecure version), and impacted AWS, N-Able, CISCO, ConnectWise and more. A vulnerability management process that tracks monitors software exposures which could impact your applications could help accelerate fixes, or ensure a move on strategy in in place for resiliency planning.
Insecure Container Images: Default vulnerabilities and insecure control parameters in container images can propagate security issues rapidly through environments.
Insufficient Access Controls: Over-privileged service or user accounts can provide attackers with easy entry points.
Hijacking Updates: Attackers infiltrate a software vendor’s development repository and insert malicious code into software updates.
Compromised Open-Source Code: Attackers target open-source code, introducing vulnerabilities into the codebase, like the near miss of XZ Utils.
Strengthening Security Measures
Strengthening security measures to discover, verify, and prevent vulnerabilities is essential for mitigating risks. This includes secure coding practices, threat assessments, secure code and release gates, image security, Infrastructure as Code (IaC) security, continuous monitoring, vulnerability management, and runtime monitoring. Implementing these practices increases security capabilities and enables strong governance decisions.
The Benefits of Integrated Security Practices
Integrating security feedback loops throughout development practices offers several benefits:
Governance of Release Decisions: Ensures that release decisions are made with security in mind.
Simplified Remediation: Facilitates targeted remediation tasks, reducing the time and effort required to address vulnerabilities.
Enhanced Application Defenses: Ensures that applications have adequate defenses to mitigate threats.
Holistic Cybersecurity Operations: Supports a comprehensive overview of infrastructure, applications, threats, defenses, and resiliency.
How Far Can Your Plan for Supply Chain Go?
A comprehensive supply chain security plan can focus on risk management, data protection, Cyber Defense, compliance, or incident response. DevOps and DevSecOps organizations can protect their supply chains from disruptions and cyber threats. These ultimately create awareness and visibility for other organizational groups to support enhanced decision making.
Actionable Steps to Protect the Supply Chain
From a combination of strategic planning, continuous monitoring, and collaboration with all stakeholders, we’ve created a short list of actions you can take to get an operating baseline to grow with. Here are some actionable steps you can take:
Review and align people, practices, technology, and integration to a standard approach such as OpenSAMM (Free) or BSIMM (paid) which incorporate foundational tactics such as:
Conduct Application Security Risk assessment
Define and Enforce data protection security and defensibility in applications
Enforce procedures, technologies and security insight into each stage of development to runtime
Assess and enhance monitoring capabilities to verify security posture and conditions for software, infrastructure, runtime in all phases (owned or third parties)
Adequately limit permissions to need to know for data and services
Assess and track software composition analysis and detailed software bill of materials
Maintain a standard and tooling to secure and consistently in development, test, and pipeline processes
Develop and test Incident Response related to supply chain (as it fits into a larger IRP)
Maintain ongoing point of contact (1:1 relationship) with critical partners
Define a standard Secure Design approach, defense in depth and development practices
Zero Trust architecture designs (landing zones, patterns, and common runtime environment [CRE])
By implementing these best practices, you can significantly enhance the security of your supply chain.
What is OpenSAMM and BSIMM?
The leading practice frameworks you should consider if you are just starting to plan for this is BSIMM (Building Security In Maturity Model) or OpenSAMM (Software Assurance Maturity Model). Both are valuable frameworks for improving software security, and both frameworks provide a benchmark and guide consistent security practices and create strategic and technical value.
The difference between BSIMM and OpenSAMM is primarily how they were created. One was from a consortium of practitioners who wanted to provide leading approach to ensure everyone could have access to a framework to secure development. BSIMM was more of a response to large organizations needing to be better at software development. In both scenarios, the goal is the same which is to incorporate consistency and stability with security practices embedded in software development. Biggest difference is OpenSAMM is free to use and BSIMM is not so much.
The main intent is to establish governance, intelligence, security in software development lifecycle, and improving environments. One of the main high-level objectives in both framework is to create the ability to observe and report security and weaknesses in software development practices so that steps can be productive and valuable to improving the posture of their secure software.
Conclusion
Securing the software development lifecycle, particularly within the context of modern, interconnected supply chains, is a critical and complex challenge. It requires not only a strategic approach but also a commitment to embedding security deeply into every phase of development and deployment. By leveraging frameworks like OpenSAMM and BSIMM, organizations can establish robust security practices that align with their unique operational needs and regulatory requirements. The integration of security into the DevSecOps process, continuous monitoring, and a well-defined incident response plan are not just best practices but essential components for maintaining the integrity and trustworthiness of business-critical applications.
Ultimately, the goal is to ensure that security is not an afterthought but a fundamental part of the development process. By addressing vulnerabilities proactively and maintaining a vigilant stance on supply chain security, organizations can better protect themselves from the ever-evolving landscape of cyber threats. The benefits of these efforts are far-reaching, from safeguarding sensitive data and intellectual property to maintaining customer trust and avoiding costly breaches. As technology continues to evolve, so too must our approaches to securing it, ensuring that our development practices are resilient, forward-thinking, and capable of supporting the long-term success of our organizations.