Biden administration accelerates software supply chain security expectations a year into Executive Order
President Joe Biden last year on May 12th signed Executive Order 14028 “Improving the Nation’s Cybersecurity”, which called on public and private sector organizations to improve the nation’s cybersecurity with “bold change” and “significant investments”. “Incremental improvements will not give us the security we need,” the EO states. Since then, the administration has only increased the pressure on agencies, forcing them to take a hard look at their software supply chains and justify their application development decisions, including how they use open source code, test their code, and grant permissions. “The federal government has accelerated its expectations for software supply chain security compliance, yet some organizations are still trying to understand how to broadly and proactively protect their software development,” says Joel Krooswyk, Senior Manager of Solutions Architecture at GitLab. “Agencies and their vendors have been focused on policy management and role-based access, but the federal government wants to go deeper and know where code is coming from and how to better secure it. They are quickly moving down the supply chain.” The interest in the origins of software code stems from the complexity of cyberattacks such as that carried out on SolarWinds, as well as the ongoing log4j and Spring4Shell vulnerabilities. “Intentionally malicious contributions can inject code that is literally opening the doors to hackers,” Krooswyk says. “However, agencies and vendors can’t just stop utilizing open source software and microservices. They need the ingenuity of the open source community.” GitLab is a proponent of open source and believes everyone can contribute. The Biden administration, through its frameworks and mandates, is simply saying, ‘we have to keep a better eye on that,’ especially as more organizations assume a cloud-first posture, according to Krooswyk. For example, earlier this year, the National Institute of Standards and Technology (NIST) published the Software Security Development Framework (SSDF) 1.1, which offers guidance on how to create tighter controls throughout the software development lifecycle. The SSDF 1.1 framework recommends: organizations should be prepared by reviewing permissions all components of software should be safe from tampering and unauthorized access software should be produced with minimal security vulnerabilities in its releases organizations should be able to quickly and sufficiently respond to vulnerabilities Take our 2022 DevSecOps survey and get a $10 gift card. Have your voice count! Code sourcing The next phase in the federal government’s move to secure the software supply chain will be to require reporting and/or attestation. “Agencies and their vendors are being asked if their software is justifiably built using properly sourced code. As a result, organizations may have to explain why they chose to use code from non-mainline repositories,” Krooswyk says. For instance, if a DevOps team chooses code from a non-mainline repository originating in China, they will have to attest to why they did that over sourcing from a mainline repository. The same idea applies to pulling clean containers and not repeatedly using those plagued with existing vulnerabilities, according to Krooswyk. He believes these questions will all be rolled up into a Cybersecurity & Infrastructure Software Agency (CISA) mandate for a software bill of materials (SBOM), which is a list of ingredients that make up software components. “The SBOM will show the list of contributors, known vulnerabilities, results of dependency scans on open source, and more,” he says. “The Biden administration, NIST, […]
