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
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, and CISA are all in alignment on the need for more consistent software security attestation.”
How to prepare
While some agencies, like the U.S. Department of Defense, might be on the cutting edge of these mandates, smaller agencies or those with more legacy infrastructure and practices might require more effort to be able to comply. “If your development, operations, and security processes aren’t transparent or fully documented and if your scanning is still manual, then these new requirements could be a roadblock,” Krooswyk says. “The administration is only going broader in terms of the scope of mandates and more specific with security requirements as time progresses to plug all the security holes, meaning more regulations and further compliance.”
GitLab believes some of the long-term asks expected to come from the government may include:
- bake security in, don’t bolt it on
- ensure scanning is top of mind
- maintain zero-trust permission models and source code management controls
- any open source software used should have known origins and support SBOM generation, verifiable by dependency scanning
- purchase secure commercial off-the-shelf software that complies with all security and labeling requirements from standards bodies
GitLab’s One DevOps Platform can help organizations answer this request for software supply chain security compliance through visibility and transparency into processes, verifiable compliance, zero-trust user management, and templated security automation. “While we are helping organizations with cloud adoption and infrastructure modernization, we’re doing so in such a way as to not compromise on risk or security, providing end-to-end traceability and step-by-step auditability from issue creation through deployment,” he says.
GitLab has a distinct set of features that make enabling NIST frameworks and attesting to code sourcing decisions easier:
- SBOM creation in a standardized format
- Security dashboards
- Vulnerability reports and remediation
- Pipeline frameworks and compliance
- Security scanning breadth of offering from SAST and DAST to fuzz testing
As the EO states, incremental improvements are not enough to properly secure software. To meet the totality, speed, and sophistication of the administration’s demands for cybersecurity protections, consider adopting GitLab’s One DevOps Platform.
