US Executive Order on Cybersecurity: What it Means for DevOps

The United States Government equates cybersecurity with national security. 

That’s the crux of the recent Executive Order that will mandate that not only must software applications be vetted, but there will be upcoming regulations on providing all of the components that make up the software. As section 1 notes:  “prevention, detection, assessment, and remediation of cyber incidents is a top priority and essential to national and economic security.”

This could sound intimidating in some ways, but is most of all relevant to those within the US Federal Government and those that do business with government entities. These groups are promised to be faced with new compliance and regulatory concerns that will rapidly spill into the private sector and become a standard across the software industry.

But what does this order mean in the short and long term?

What to Expect

In just less than 60 days, the order indicates that new regulations will be published, including “guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing).” While we don’t know the exact regulations, it’s safe to say the focus will be on not only performance testing, but also on how software is built, the testing and manufacturing process – the software manifest or software bill of materials (SBOM).

But make no mistake: the US government is beginning to awaken to the danger of cyber attacks, and this will have a huge industry impact.

What is a Software Bill of Materials (SBOM)?

For those not familiar, what is a SBOM? Much like a car, software consists of many smaller parts that are designed to work interdependently. And the complete package (car) can only operate properly if every component is functioning as designed. In a software supply chain attack – such as the recent SolarWinds example – the “car” had components that were compromised before arriving on the assembly line, which could cause the car to malfunction. 

The current order will require companies to not only sell the best “car” to the government, but also provide details on all of the contained components (like spark plugs and light bulbs). 

While many vendor solutions on the market can scan software to provide this list of materials, JFrog takes it a step further: we not only know the components, but where those components came from, their function, how they were assembled into the car, and the environment in the factory. We can then use this data to help companies make data-driven business decisions, such as stopping the assembly line automatically. We don’t just provide the listing of materials – we are uniquely the end-to-end process that creates the manifest itself.

What Will be Required

Beyond the SBOM as “just a list” of components, the order further indicates that there will be a focus on “ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product…” or “… secure software development environments, including such actions as:

1. using administratively separate build environments;
2. auditing trust relationships;
3. establishing multi-factor, risk-based authentication and conditional access across the enterprise”

This emphasis further indicates that not only proprietary software, but also open source and third-party software components and development and testing environments themselves (“documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software”) will be under scrutiny for potential risk of a newly discovered vulnerability as part of the SBOM deliverables.

What does this mean for developers and DevOps practitioners in the mid- and long-term? Shifting left will now be an integral component of nearly all software delivery in short order, as the private sector adopts these standards in order to be in compliance for themselves, their customers, and their customers’ customers.

How to Prepare

Regardless of the standards coming our way in the next several weeks, I believe companies will be best positioned to succeed if they can:

• Provide a complete inventory of their software components and their usage in the company – a single source of truth 
• Scan all software packages for vulnerabilities and known risks
• Secure repositories of source code and binaries from upstream, supply-chain attacks (and demonstrate this ability)
• Provide impact analysis of discovered components
• Provide detailed information on development environments and pipeline components
• Attest to the security of every step in the pipeline build process
• Ability to automatically halt dangerous, untrusted or infected processes to prevent continuance
• Provide cryptographically signed and validated releases
• Provide all of these details as part of the SBOM generated in immutable fashion

At JFrog specifically, we’re looking into all of these areas, and thankfully many of these features and components are already available out of the box. I look forward to working with partners and customers on the most efficient, effective ways to meet these requirements as they become more clear from the US government.

Enjoyed this post? Watch the free webinar recording “Joe Biden’s Security Order: What it Means for DevOps“