As a response to the spate of high-profile software supply chain attacks, including SolarWinds and Log4J, President Biden’s cybersecurity Executive Order 14028, released in 2021, signaled the beginning of the administration’s focus on software supply chain security. The executive order demonstrated the administration’s serious commitment to the issue and made clear to software companies that they had a vital role in maintaining security.

Vendors subject to the EO and selling to federal entities are requested to submit letters of attestation for compliance. While the original deadlines for critical software and all software were June 12 and Sept. 14, respectively, the White House just recently announced that the deadline will be extended. Agencies will start to collect attestations for critical and all software no later than three and six months, respectively, after the Cybersecurity and Infrastructure Security Agency’s common attestation form is finalized.

The compliance will result in a trickle-down (or perhaps trickle-up) effect of significant improvements in security across the software supply chain since almost every company is both a consumer and a provider of software, for which compliance is required. There are numerous boxes that vendors need to tick for EO compliance, including generating a software bill of materials (SBOM), which will be discussed. And recently, on top of the EO came the National Cybersecurity Strategy, building on the administration’s goal of securing the software supply chain. What does it signify, and what could it mean for vendors?

Shift of liability will require shift of strategies

The administration’s unveiling of the National Cybersecurity Strategy, almost two years after the EO, includes a subsection that calls for the shift of the liability for insecure apps to vendors, as well as for software providers to deploy more secure software development practices. This particular subsection uses the National Institute of Standards and Technology’s Secure Software Development Framework (SSDF) as a foundation, which provides recommendations for mitigating the risk of software vulnerabilities. With this implemented, any company shipping software would be responsible for ensuring the security of both the software and its components. This is a sweeping stance, pointing to a new direction for software security. Though this may not become legislation for years, vendors should prepare in ways that they can now; it’s an opportunity to ensure that software supply chains are secure for both federal contracts and private ones, so that organizations can stay ahead when the mandates come for everyone.

Security is beyond protecting code

As laid out in the SSDF, there are over 40 requirements that organizations must fulfill, which are far beyond just securing code. We see those controls fit into three categories: code and application scanning, enforcement of a secure development process and code integrity, and the hardening of the development tools. While most organizations should already have code security in place, the other two necessary layers — process and infrastructure — are relatively new concerns for software vendors. To ensure compliance and assume the responsibility for preventing vulnerabilities, security strategies will likely need to be restructured within many organizations.

As a first step, software companies should review the new guidelines and treat them as a checklist for their company’s security plans. Once an audit is complete, organizations that act quickly will be in better positions to identify and use purpose-built solutions that can quickly and easily help them move into compliance. However, larger enterprises may want to consider bringing on specialized tools that address specific architectures and structures.

SBOMs for increased transparency

The SBOM is a key building block in software security and software supply chain risk management. It is best thought of as an inventory checklist — something that a company produces to accompany its finished software so its users know which components, tools, libraries and processes were used to create the finished product. There are already accepted minimum SBOM guidelines from CISA and NIST, but with cybersecurity compliance deadlines approaching, it is more important than ever for organizations to take serious steps to act on them.

For many organizations, it can feel like they are airing their dirty laundry by creating an SBOM since it is a complete inventory checklist of components that make up a software product. However, if developers are focused on security throughout the full application lifecycle, the SBOM will demonstrate a risk-free product. Organizations that can demonstrate security through an SBOM will have a leg up over competitors riddled with vulnerabilities. Those with clean products, as shown through SBOMs, will be deemed winners in the public and private sectors.

Additionally, while there has been much-needed progress on ensuring that what’s released is secure, it’s also important to focus on the security of live and running applications. The discovery of a zero-day can suddenly turn a secure application into an insecure one, and make companies scramble and strain precious resources to remediate, so visibility is key. Mandating that tools track the live status of all of an application’s components — and potentially even assist organizations in remediating vulnerabilities within them, once discovered — will have a profoundly positive impact on day-to-day security, making it harder for attackers to infiltrate, thus increasing security for stakeholders.

Tips to consider for developing SBOMs

There has been an increasing focus, both in the public and private sectors, on transparency in software development, and the SBOM is an essential element in a security and compliance toolbox to ensure that software is continuously up to date and verified.

Here are some tips for vendors to consider:

• Have full visibility into all components developers are using. This is the first critical step, which should be done quickly.
• Ensure that there is clear communication between the development team and security team. This sets expectations for what components can and cannot be included in a product, which can be reflected in the SBOM, as a single source of truth for the teams.
• The SBOM can be as valuable internally for visibility and transparency as it is externally to customers and regulators.
• The SBOM is not something that should be created manually. It is key to use SBOM management software with full visibility into the development pipeline to reliably generate output in accordance with federal measures.

After major software supply chain attacks have proven that one vulnerability can lead to catastrophic results, there is little tolerance for errors with security. Becoming familiar with new federal guidance and the associated deadlines is a good first step for organizations to take in order to create a comprehensive security strategy that is in line with the guidelines. Additionally, vendors that strive for transparency through SBOM creation will be able to meet those expectations, gain trust in the public (and private) sector, and stay ahead of the competition. Finally, finding a vendor that creates a tool that is purpose-built for software supply chain security guidelines could be a valuable step to help organizations comply with the current and dynamic future guidelines, especially as the threat landscape continues to evolve.

Eilon Elhadad is senior director of software supply chain security at Aqua Security.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.