Software supply chain attacks, such as the recent one involving MOVEit Transfer, are a serious issue for modern enterprises. Their dependency on third-party software makes it difficult to successfully vet the security integrity of every product used by enterprises. Software is especially difficult to assess securely, as it can be modified through updates throughout its lifecycle. For threat actors, targeting popular enterprise software tools is a lucrative and time-efficient way to gain access to the systems of a large number of corporate users.
Verifying the integrity of software, and using attestation services, is one way to minimize the threat surface. So how can these concepts be leveraged in software? Software integrity (also known as code integrity) refers to the quality of the source code and allows the determination of the safety, security, and reliability of the software. It can mean that the code is unaltered by unauthorized parties, or it can also provide protection against hacks and guarantee privacy. Integrity checking can be relatively complex, but includes, at a minimum (from a security perspective), security features and ensures that security vulnerabilities have been eliminated. It does what it should, can be tested, and is easy to understand and edit, without introducing new errors or flaws. There are code analysis tools that can enable this.
Beyond that, the code can be signed through the application of a digital signature to seal that integrity check. This can happen several times during the lifetime of that software: at production, for upgrades and patching, etc. This provides assurance that the software came from the developer and that it has not been changed in an unauthorized manner. This proof of authenticity becomes important in supply chain scenarios, and can be an important tool for brand protection of the developers.
Code signing makes use of digital certificates; the signature is cryptographically hashed and packaged in a certificate. This certificate can then be verified by the user of the software through a Public Key Infrastructure (PKI), with a certificate authority validating (or refuting) the applied signature. There are various types of code signing certificates: standard and extended. The latter involves a more complex process and stricter requirements for validation and key management.
Software attestation is essentially the other side of that process. It’s a trust mechanism that allows the user to independently validate the integrity asserted by a provider. Attestation might require not just the vendors name, version of the software, and origins of the code, but also other software artifacts, such as statements to the effect that they have followed secure development practices, information on external dependencies used to build it, the build process itself, the test suites that were run, and any security checks passed. Together, these artifacts form the metadata of the software, which then can be independently signed. A PKI can then be leveraged to verify the applied digital signature.
There are software attestation standards that can be leveraged, including open ones (in-tot and Binary Authorization being two popular ones). The U.S. Cybersecurity & Infrastructure Security Agency (CISA) is working on a self-attestation form (Secure Software Development Attestation Common Form) for software producers serving the federal government. The form will require them to confirm implementation of specific security practices. This was following the White House’s 2021 Executive Order 14028 and the Office of Management and Budget’s (OMB) M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.”
Digital signatures for code integrity and software attestation will increasingly be in demand, especially as governments on both sides of the Atlantic (in the European Union and the United States) are pushing for policy and regulation on mandatory Software Bills of Materials (SBOMs). The goal is to make software developers and device manufacturers accountable for the components that make up their products.
An SBOM will have to list known vulnerabilities associated with each component (open source and third party), pushing security rights to the forefront of product development. This visibility will allow for product development teams, DevOps, and implementers to address vulnerabilities and thereby strengthen security. SBOMs will likely form part of the software’s metadata, so signing will have a role to play here.
In short, code signing and software attestation can both confer a level of security that can minimize the threat of a supply chain attack. It’s important to keep in mind, however, that they won’t address all issues, and will not be 100% fool-proof either. Of course, threat actors know this, and many are already targeting the code signing process in order to inject malicious code. This requires threat actors to compromise development platforms where code signing takes place.
Ultimately, the use of digital signatures, from creation to management, is another aspect that will need to be secured from a developer perspective. DevSecOps will also have an important role to play here in order to avoid such malicious tactics, thereby providing a holistic security context for using digital signatures. But there is no doubt that digital signatures are a key technology for code integrity and software attestation, and will have a positive impact on thwarting the progress of supply chain attacks, if used widely.
Sources: