In recent years, the software supply chain has become a prime target for cybercriminals, leading to a wave of new regulations and requirements aimed at bolstering security. From government mandates to industry best practices, organizations are now facing increasing pressure to secure their software development and deployment processes.
The turning point came in May 2021 when President Biden signed an executive order on cybersecurity. This landmark directive introduced self-attestation requirements for software producers selling to the federal government and hinted at the need for Software Bills of Materials (SBOMs). This set the stage for a cascade of guidelines and regulations that would follow.
The National Institute of Standards and Technology (NIST) released its Secure Software Development Framework, providing a comprehensive set of best practices.
The release of the NIST Secure Software Development Framework provides a standardized and comprehensive approach to secure software development. This framework helps organizations identify and implement best practices, improving the overall security of the software supply chain. This consistency and thoroughness in addressing software security issues represent an essential step forward in the industry.
The Office of Management and Budget outlined a timeline for self-attestation to NIST requirements for federal contractors.
The timeline outlined in the OMB Memo (September 2022) included several key deadlines for federal contractors:
These deadlines were set to ensure a phased and manageable implementation of the NIST guidelines across all federal contractors, aiming to enhance the security of the software supply chain within a reasonable timeframe.
This act extended software supply chain security requirements to all products sold in the EU, not just those sold to governments. This is important because it broadens the scope of security regulations, ensuring that all software products, regardless of their end users, adhere to high security standards. This helps to protect consumers and businesses from cyber threats and vulnerabilities in software products available in the EU market.
New requirements were introduced for medical device cybersecurity, including software supply chain considerations. This is significant because it addresses the unique vulnerabilities of medical devices, which can have direct impacts on patient safety. By focusing on software supply chain security, these requirements aim to prevent cyberattacks that could compromise medical devices, ensuring that healthcare systems remain safe and secure.
This EU regulation focused on third-party risks for financial institutions. This is crucial because financial institutions often rely on third-party vendors for various software and services, which can introduce vulnerabilities into their systems. By regulating third-party risks, DORA helps to ensure that financial institutions maintain robust security practices across their entire supply chain, protecting sensitive financial data and maintaining operational resilience against cyber threats.
The Biden-Harris administration highlighted the growing threat of software supply chain attacks and signaled potential future regulations. This is important because it acknowledges the increasing frequency and sophistication of software supply chain attacks and the need for a coordinated response. By signaling potential future regulations, the strategy sets the stage for stronger security measures and encourages organizations to proactively improve their software supply chain security to align with anticipated regulatory requirements.
While regulations provide a framework, industry leaders have also stepped up to offer best practices:
This guide provides detailed principles for making software secure by default. It emphasizes building security into the software development process from the beginning, rather than adding it as an afterthought. By following these principles, organizations can create software that is inherently more resistant to vulnerabilities and attacks, reducing the risk of security breaches.
These recommendations focus on securing continuous integration and continuous delivery (CI/CD) environments, which are critical for modern software development. CI/CD pipelines can be vulnerable to various attacks if not properly secured. The guidance helps organizations implement best practices to protect their CI/CD processes, ensuring that software releases are secure and free from tampering.
This guidance addresses the management of Software Bills of Materials (SBOMs), which are inventories of all components and dependencies in a software application. Managing SBOMs effectively helps organizations track and address vulnerabilities in third-party components, enhancing the overall security of the software supply chain.
Organizations are employing a variety of tools to meet the new requirements:
Software Bills of Materials (SBOMs): SBOMs provide a detailed inventory of all code and dependencies used in a software application. This transparency helps organizations identify and address vulnerabilities in third-party components, ensuring that all parts of the software are secure.
Software Composition Analysis (SCA): SCA tools actively scan for known vulnerabilities in open-source and third-party components. By identifying and addressing these vulnerabilities, organizations can reduce the risk of security breaches and ensure that their software remains secure.
CVE Tracking: Ongoing monitoring of publicly disclosed cybersecurity vulnerabilities, known as Common Vulnerabilities and Exposures (CVEs), helps organizations stay informed about potential threats. By tracking CVEs, organizations can quickly address vulnerabilities as they are discovered, maintaining the security of their software.
Artifact Signing: Cryptographic verification of software integrity ensures that the software has not been tampered with or altered. Artifact signing helps organizations verify the authenticity and integrity of their software, providing assurance that it is secure and trustworthy.
SLSA Framework: The Supply Chain Levels for Software Artifacts (SLSA) framework provides a comprehensive approach to supply chain security. It outlines best practices and guidelines for securing the entire software supply chain, from development to deployment. By following the SLSA framework, organizations can enhance their security posture and reduce the risk of supply chain attacks.
While these methods represent a significant step forward in helping organizations comply with the best practices and regulations outlined above, they are mostly pre-deployment controls, and wouldn’t do anything about software supply chain attacks like Solar Winds or Codecov. In light of these gaps, RAD Security has proposed verified runtime fingerprints as a way to transparently verify the behavior of a container image. The open source runtime fingerprint catalog shows transparent fingerprints for popular open source images, as well as multiple versions of those images to understand the difference in behavior across releases.
The open source RAD Catalog
With these fingerprints, the idea is that RAD Security uses behavioral baselines of your unique good behavior to detect zero day attacks in your software supply chain and cloud native environment. Integrated, real-time identity and infrastructure context sharpen inputs into shift-left and posture management, and response actions allow security and engineering teams to right-size identities, implement guardrails for infrastructure and respond to attacks in the workload as they happen.
In the fingerprint below, you see behavioral drift that has been interpreted as a reverse shell attack.
Reverse shell attack drift example from RAD Security
While there are plenty of examples of best practice guidance, and a burgeoning level of new compliance regulations around software supply chain security, truly responding to the large wave of software supply chain attacks will require more than just pre-deployment tools for creating an asset inventory or package search for CVEs. It will require a new level of behavioral detection and response that is portable, transparent, and can work in runtime as well as in the software supply chain.
Get in touch with the RAD team to talk about using behavioral runtime verification in your environment today!