Industry Talk

Regular Industry Development Updates, Opinions and Talking Points relating to Manufacturing, the Supply Chain and Logistics.

Addressing Supply Chain Security Compliance Obligations

A recent study has found that inadequate software supply chain security and getting to grips with new compliance regulations are two top worries keeping CSOs up at night.

Research conducted at Cloud Expo Europe in March 2023 found that 36.9% of UK organisations have significant concerns with regard to software supply chain security. Meanwhile, just 36.9% were confident of being able to adopt a raft of new security compliance obligations and frameworks within the required timeframes.

With Gartner estimating that more than 95% of new apps will be deployed on cloud-native platforms by 2025 and software supply chain attacks on the rise, UK organisations will need to act fast to address supply chain security and eliminate any confusion regarding new security standards.


Examining the challenge

Despite the fact that 34% of UK organisations now have a cloud native security strategy in place, supply chain vulnerabilities remain a source of anxiety for 37% of organisations who say their concerns are focused on two primary areas: open source software vulnerabilities and flaws that could be exploited (47%), followed closely by third party vendor risk (44%).

In addition to these issues, organisations are also grappling with challenge of complying with a plethora of new supply chain security obligations. Confronted by no fewer than four best-practice guides and two communications from the US federal government, including Executive Order 14028, 52% of UK organisations say they are struggling to meet deadlines or understand the fine print. So much so that only 22% are planning to adopt SBOM standards such as Cyclone DX and SPDX, and just 11% plan to implement NIS2 guidelines.


Navigating the path ahead

To navigate with clarity the path ahead, the following seven recommendations will help organisations understand what they need to be compliant with and how to demonstrate compliance in relation to how they protect the code, tools and processes used to build software.


Recommendation 1:

The 2022 White House memorandum on enhancing the security of the software supply chain through development practices is a key document that contains deadlines for compliance with specific guidelines.

Issued in September 2022, the White House memo was the first document with specific guidelines and compliance deadlines for meeting the requirements set out in the NIST’s Secure Software Development Framework (NIST 800-218). Organisations can use the memo to understand the list of software supply chain compliance deadlines and scope, and use NIST 800-218 to understand these requirements.


Recommendation 2:

If you sell to a US federal agency, or supply companies that sell to federal agencies, you are now required to comply with NIST 800-218 guidelines in the form of self-attestation.

Federal agencies can only use software from producers who can attest to complying with US government specified secure development practices as described in the NIST Guidance.


Recommendation 3:

The only guide that counts towards self-attestation and compliance is NIST 800-218.

Best practice guides issued by the CNCF, Google (now the Linux Foundation), the CIS, NSA, CISA and ODNI contain helpful tools on how to self-attest, but you should only measure your compliance by the NIST 800-218.


Recommendation 4:

Use the draft self-attestation forms available in the NIST 800-218 FAQ and the NSA, CISA, and ODNI Recommended Practices Guide for Developers.

If you don’t have a third party attestation, for example FedRAMP compliance, use these self-attestation forms to get started today.


Recommendation 5:

The SBOM is not a self-attestation tool in and of itself.

Simply creating a software bill of materials (SBOM) and supplying this to a federal agency isn’t sufficient for self-attestation, as NIST sets out explicit requirements that an SBOM may not necessarily address. For example, vulnerability fixes, third-party licence information, new vulnerability notifications and a process for publishing updates and patches that address new vulnerabilities aren’t always to be found in SBOMs.


Recommendation 6:

Organisations that focus on going beyond using a code repository to create an SBOM will benefit from achieving a more helpful, all-inclusive SBOM that saves more time.

Using the CI/CD tool to create an SBOM will deliver a lot of the application context that’s needed to attest to the security and authenticity of products included in the product: where the artifact is located in the pipeline, what security checks have been run, when the artifact was built, who did the commit, the configurations of the environment, if images were digitally signed, pending security vulnerabilities, and so forth. Creating SBOMs that incorporate proof of appropriate security checks in addition to basic information such as third-party libraries used, packages, and artifact versions produced will save valuable time when creating self-attestations.


Recommendation 7:

Utilise self-attestation forms from NIST or the appendix of the NSA, CISA and ODNI guidelines to cover people and processes.

NIST 800-218 uniquely contains guidance around people and processes and organisations will need to attest to proper preparation of the organisation, including delivering adequate visibility into roles and responsibilities.

By implementing true end-to-end security solutions that keep their software supply chain and utilising these recommendations, organisations will be able to stay secure and remain compliant in the most streamlined and effective way possible.