A New Hope for Software Security
upstart writes:
From package signing to SBOMs to new developer toolchains, the pieces for securing the software supply chain are starting to come together:
The Log4j vulnerability in December 2021 spotlighted the software supply chain as a massively neglected security surface area. It revealed just how interconnected our software artifacts are, and how our systems are only as secure as their weakest links. It also reinforced the idea that we may think security is something we can buy, but really it's about how we function as development teams.
Ever since, we've been sprinting to improve.
[...] What's starting to pull all of this together-and create more urgency to create a cohesive strategy around software signing, SBOMs, and developer workflow-is regulation, which would demand stricter ownership of the integrity of software security.
Back in April, the Cybersecurity and Infrastructure Agency (CISA) published a request for comment on a newly proposed Secure Software Development Attestation Form that will put the onus on the CEOs of software companies to attest that their software has been built in secure environments and that good-faith, reasonable efforts have been made to maintain trusted source code supply chains.
What counts as "reasonable?"
Thus far, "reasonable" efforts seem to be the guidelines set forth in FedRAMP's Vulnerability Scanning Requirements for Containers and the National Institute of Standards and Technology's Secure Software Development Framework. But the far more nuanced, read-between-the-lines interpretation of the new self-attestation requirements is in the clauses that cover third-party code incorporated into the software. In short, software providers will be held liable for the unfunded, unmaintained popular open source they use in their supply chains.
Wait, what? Responsible for some random project maintainer's code? Apparently, yes. Is that "reasonable"?
This is a somewhat shocking, if necessary, check on unfettered adoption of open source. I'm not suggesting that companies shouldn't be using open source, quite the contrary. I'm reminding you that there is no free lunch, including when it comes packaged as free (and open source) software. Someone needs to pay to keep the lights on for maintainers, and someone needs to help developers make sense of all this inbound, open source software.
Read more of this story at SoylentNews.