Skip to content

[Security Week] Industry Reactions to Govt Requiring Security Guarantees From Software Vendors

Security Journey Security Week Govt Software

Published on

This article was originally posted on Security Week.

The White House has announced new guidance with the aim of ensuring that federal agencies only use secure software.

Building on the cybersecurity executive order signed by President Joe Biden in May 2021, a memorandum from the OMB requires federal agencies to comply with NIST guidance — for secure software development and supply chain security — when using third-party software. In order to ensure compliance, agencies will have to at least obtain a self-attestation form from software developers whose products they are using or plan on using.

The forms must be obtained within 270 days for critical software and within one year for other software.

Feedback Friday

The OMB noted that self-attestation is the minimum level required, but agencies can also make risk-based determinations for a third-party assessment if the product or service that is being acquired is critical.

Agencies can also require a software bill of materials (SBOM) and other artifacts that can prove the vendor’s compliance, and they can also require the company to run a vulnerability disclosure program.

CISA has been tasked with creating a standard self-attestation form that can be used by agencies.

Some experts believe this initiative is a step in the right direction, while others point out that there is still a lot of work ahead, or are skeptical that it will have the desired result.

Yotam Perkal, Director of Vulnerability Research, Rezilion:

“Stating that a Software Bill of Materials (SBOMs) may be required by the agency in solicitation requirements isn’t good enough as software is dynamic and so are the components within it. Dependencies change over time or become obsolete. While requiring these attestations is definitely a step in the right direction, as it stands now, meeting NIST’s security best practices is required only once with an SBOM, which is only a snapshot in time of software dependencies and does not provide the real-time context that organizations need to truly see their attack surface.

Unless the SBOM is provided per version, or the entity that consumes the product has some way of generating updated information when a vulnerability like Log4Shell surfaces, organizations will still struggle to understand whether or not they are affected. Also, it notes an SBOM is only a recommendation and not mandatory. This doesn’t go far enough.

I think it is crucial to ensure the format of this “common form” is machine readable to allow for automation and ease of consumption/sharing. And again, it is paramount that these attestations will be live documents that are updated as new versions of the software are released to keep them from going stale and getting to a point in which they no longer reflect the real security posture of the software.”

Rhys Arkins, Vice President of Product Management, Mend:

“The release of this memo highlights the growing need to secure the software supply chain and that the US government is committed to helping organizations identify best practices to remain secure. At this time, it’s hard to tell whether this guidance will result in any significant change as some of the requirements are fairly subjective. For example, the guidance to use forms of risk modeling to help assess the security risk for software is an easy tactic an organization can take without changing much of their larger strategy. Looking ahead, to build upon this and elicit real change, the US government will need to ask for detailed proof and justification and be willing to make decisions based on these responses. These actions will push organizations to do more than just check boxes.”

Sounil Yu, Chief Information Security Officer, JupiterOne:

“I’m surprised to see that “cloud-based software” is included in the scope of this memo. Although my company JupiterOne has published our SBOM for anyone to see, the community working to define SBOM standards of practice has not come to agreement on the value of an SBOM for the downstream customers of the cloud-based software. As such, it may be premature to include this category of software.

At the same time, I’m surprised to see that agency-developed software is not included in the scope of this memo since the community universally agrees that the developer of the software should track their own supply chain.”

Tom Kellermann, CISM, SVP of Cyber Strategy, Contrast Security:

“Software supply chains are under siege. Cybercriminals and spies are attacking software development, integration, and delivery infrastructure. Hijacking of the government’s digital infrastructure allows for adversaries to conduct island hopping, which increases the need for expanded national security and economic security enforcement. Given the sophistication of recent software supply chain cyberattacks, ensuring software integrity is paramount to protecting Federal systems systemic cyberattacks. Because of that, I applaud this proactive mandate by the administration. Continuous monitoring must expand to software development. As a next step, the administration should expand the guidance to include automation of interactive application security testing to ensure vigilant digital transformation.”

Tim Mackey, Principal Security Strategist, Synopsys Cybersecurity Research Center:

“We are very early in the SBOM era. Most vendors are still working to create SBOMs and that will continue for the foreseeable future. While a vendor being able to provide an SBOM is an indicator of open source security acumen, it isn’t the only indicator of overall security acumen. Importantly, if an agency requests an SBOM from a vendor but doesn’t have a workflow to process that SBOM and derive value from it, then having a vendor provide SBOMs adds cost for that vendor without benefit. What the memo does set out is that vendors should be prepared to have SBOMs for their products within the next year, and that vendors should expect agencies to have a streamlined process to request and retain attestations.”

Mike Burch, Director of Application Security, Security Journey:

“The latest software security requirements announced by the U.S. government follow a positive progression towards better cyber hygiene across the U.S. – including recent guidance from NSA, CISA and OpenSSF. It’s exciting to see so much focus on building a safer supply chain and protecting organizations – especially from the government as one of the largest purchasers of products and technology in the country. We now hope that other enterprises follow suit, and software companies rise to the occasion.

Yet what we’re still seeing across application security is a focus on finding and fixing known vulnerabilities. There is far less training and importance given to taking a proactive approach and baking-in security from the very start. To truly support a safer, securer supply chain, it’s time everyone across the software development lifecycle recognizes the value of a security-first mindset. But it’s not necessarily up to the developer to solve this problem. Instead, organizations need to support and invest in education initiatives that provide secure coding knowledge and empower their teams to make safer decisions.”

Mark Stamford, Founder and CEO, OccamSec:

“No doubt this was done in consultation with the same private sector vendors as always — large companies, who have a vested interest in certain outcomes — so is this really going to create a secure environment? Or a nice revenue increase?

Information sharing continues to be a one way street — private sector informs feds, feds will act, private sector gets some snippets back. Ideally the Feds will provide updates because they see far more given their capabilities. Until we have close to real-time alerting coming from the Government we are always going to be in a weaker spot and not maximizing the capabilities we have.

What we need really is a more dynamic approach which is constantly re-assessing how the risk posture has changed following a new threat/vulnerability/other — without this we will have standards set, which get updated every once in a while, but always playing catch up.”

Rick McElroy, Principal Cybersecurity Strategist, VMware:

“This order attempts to address significant cyber security weaknesses and shore up governmental agencies’ control framework. It aims to modernize their approach to public-private intelligence sharing and move the agencies towards zero trust. These are all worthy and long overdue goals. The executive order continues to show this administration’s commitment to a stronger cyber defensive posture.

While the timeline seems aggressive based on typical procurement times from agencies, I believe this order will meaningfully move the needle for public sector security. This guidance will have a major impact on any provider of technology services or software to governmental agencies. Suppliers of these services and technology should be prepared to respond to the requirements of this order.”

Andrew Hay, COO, LARES Consulting:

“As CISA has previously stated, a SBOM is a key building block in software security and software supply chain risk management. I see the self-attestation requirement for vendors as an initial stepping stone to getting organizations used to compiling such information for public consumption. Down the road, we’ll likely see more stringent requirements like third-party attestation, certification, and accreditation to better protect the software supply chain.”

James McQuiggan, security awareness advocate, KnowBe4:

“The documents coming forthwith are guidance and not regulation. Unlike the FEDRamp compliance, where it’s mandatory, this supply chain security is written as guidance. It should be integrated with the FEDRamp compliance to ensure that all organizations providing software or software services to the government comply with the criteria in the soon-to-be-published guidance. Included in the guidance is a requirement of training.

However, this training is not to develop secure software but to understand the guidance and how to implement it within the supporting organization. If organizations can provide Secure Development LifeCycle (SDLC) training to their developers and integrate those concepts into their organization’s culture, it will effectively improve the quality of the software. Having security top of mind and embedded into the culture for all users can reduce the risk of data breaches, leaks, and misconfigured software.”

Moshe Zioni, VP of Security Research, Apiiro:

“The White House’s executive order highlighting the use of a Software Bill of Materials (SBOM) for federal agencies is a step in the right direction – optimal security practices are continuing to become a major priority for both public sector and private organizations and the SBOM is a critical element.

There are countless benefits to having a document tracking the supply chain in software development, including faster incident response, penetration testing, vulnerability remediation, and license tracking and verification. These features are relevant for many audiences, including those producing, maintaining and simply using software. We hope to see further adoption of the SBOM across all sectors as well as continued legislation promoting cybersecurity and threat prevention.”