When the Biden administration released Executive Order 14028, “Improving the Nation's Cybersecurity”, it included guidance to enhance the security of the nation’s software supply chain. As a result, key building blocks are being developed to both strengthen software security and bolster software Supply Chain Risk Management (SCRM) programs across the Federal government.
During many recent security incidents, we hear a lot of messages about the lack of knowledge of the code dependencies, attacks to the software supply chain, Software Bill of Materials (SBOM), digital signatures, provenance, attestation, etc. The fact is, every time a new vulnerability appears in the landscape, we usually need to spend a lot of time and effort to detect the real impact on the applications and services that are running in our environment.
The proliferation of third-party software components such as open source software(OSS) has triggered a growing need to keep track of it all. Why? Because when security vulnerabilities inevitably crop up in open source components, it’s pretty important to know whether your company uses that piece of code – or whether it appears in the myriad software dependencies inherent in open source.
Speaking to people on our neighbouring booths at the UK nuclear decommissioning event, it was clear to see the entire industry is drowning in paperwork.
SCITT in the information security context stands for “Supply Chain Integrity, Transparency, and Trust”. It’s a relatively young discipline and the dust is still settling over its scope and definition but the core is very simple: risk vests in the operator of equipment, but it originates at every point in the supply chain.
Trust is a very broad and complex topic, and consequently there are very many definitions of Zero Trust that can be confusing as they try to capture the nuance and details and scope that the problem of trust raises.
