When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
The software supply chain is a complex ecosystem connecting the dots between the development, distribution, and deployment stages of software.
Owing to this complexity, it’s become a prime target for cyberattacks. As we’ve seen in many cases, malicious actors can exploit vulnerabilities at any point within the chain to inject malware, steal sensitive data, or disrupt critical infrastructure.
For instance, last year saw Voice over IP (VoIP) vendor 3CX disclose that a version of its 3CX Desktop software was distributed to thousands of customers with malicious codes. The infamous SolarWinds Attack is another software supply chain incident that left multiple U.S. governments vulnerable for months.
Meanwhile Microsoft is currently under attack with hackers breaching the company’s source code.
In response to this growing threat, the Cybersecurity and Infrastructure Security Agency (CISA) last week introduced a new attestation form for software suppliers.
The form mandates that software makers who are partners with the U.S. Federal Government must confirm their adherence to secure development practices.
This is not merely a requirement but a strategic move to preemptively address potential vulnerabilities right at the development stage of software products.
However, the initiative has ignited a mixed reaction within the industry, with some lauding it as a necessary step forward and others expressing concerns about potential roadblocks.
Key Takeaways
- Software supply chain attacks are an increasing cybersecurity threat for U.S. Government agencies.
- CISA has introduced a mandatory attestation form requiring software vendors selling to the U.S. government to confirm adherence to secure development guidelines.
- The form aims to increase visibility into software suppliers’ security posture, drive executive accountability, and standardize security assessments across the software ecosystem.
- Potential challenges include a lack of security maturity at some suppliers, the form omitting certain key practices, and the need for protections beyond just the attestation.
- Experts recommend actions like separating production and development environments, using secure coding practices, enabling MFA/encryption, continuous monitoring, and embracing an overall culture of software security.
- While a positive step, the form represents foundational practices – suppliers must look inward to identify gaps and foster a true culture of software security beyond just checking compliance boxes.
What the Attestation Form Means
The new attestation form requires software makers selling to U.S. Federal Agencies to attest to meeting minimum secure development requirements based on the NIST Secure Software Development Framework (SSDF). This attestation is mandatory for the government’s continued use of their software.
The requirement applies to a wide range of software developed or significantly modified after September 14, 2022, including firmware, operating systems, applications, cloud-based software, and other application services.
However, it exempts software developed by federal agencies, open-source software directly obtained by agencies, components incorporated into software end products, and freely obtained and publicly available software.
According to CISA, the repository for online form submission will be made available later this month.
The Attestation Form Offers Three Key Advantages
Firstly, it increases transparency and provides structure around suppliers’ proof of compliance, says Javed Hasan, CEO and Co-founder of Lineaje.
“The form provides a structured approach for software suppliers to attest to the security of their products and comply with U.S. Executive Order 14028.
“It shows the importance that CISA has put on the use of software bills of materials (SBOMs) to ensure a more secure software supply chain. It also aligns with NIST guidelines and provides reliable self-attestation that can be independently verified.”
Standardization is another key thing that rings a bell in the attestation form. Traditionally, security assessments have been conducted in an ad-hoc manner, with each buyer employing their own set of criteria. This lack of uniformity created confusion and inefficiencies for both suppliers and buyers.
The CISA attestation form establishes a common language for security assessments, allowing suppliers to prepare a single attestation that can be submitted to multiple buyers. This standardization reduces redundancy and streamlines the security evaluation process for all stakeholders.
The third key advantage is that CEOs will have to get as active as possible in ensuring software security rather than watching from a distance.
Explaining this new development, Neatsun Ziv, Co-Founder and CEO at OX Security, told Techopedia:
“The role of the CEO in this paradigm extends beyond oversight. It demands active engagement with their teams to foster an environment where security is not an afterthought but a foundational element of software development.
“This involves not only understanding but championing the practices laid out by CISA, from ensuring secure development environments to maintaining stringent controls over software components and their provenance.”
Potential Hurdles on the Road to Security and Compliance
While the potential benefits of CISA’s attestation form are undeniable, experts raise concerns about its implementation. Chris Hughes, chief security advisor at Endor Labs and Cyber Innovation Fellow at CISA, pointed out to Techopedia that the form represents some fundamental secure development practices, but some key pieces are missing in the puzzle.
He noted that the biggest challenge lies with software providers who do not have a firm grasp of secure software development practices or security frameworks such as NIST’s SSDF, OWASP SAMM, or BSIMM.
Hughes said:
“The biggest challenges to meeting the requirements will be for those suppliers who haven’t implemented secure software development practices or leveraged frameworks such as NIST’s SSDF, OWASP SAMM, or BSIMM.
“They will need to assess their current development practices, identify deficiencies, and implement plans to rectify them.
“This, of course, takes time and resources, which smaller startups and immature organizations have finite access to, especially against competing demands for speed to market, revenue, return for investors, feature velocity, and more.
“This could lead to some suppliers exiting or avoiding the Federal market due to the higher level of maturity required and potentially limited access to innovative commercial software solutions for the Federal government.”
Another significant worry, Hughes suggests, is that the form missed out on some key practices necessary for driving a secure software supply chain.
“Some key practices seem to be neglected, such as the need for threat modeling to enable secure-by-design systems. It also lacks any mention of memory safety, which has ironically also been a core message from CISA in other avenues.”
Shawn Loveland, Chief Operating Officer at Resecurity, also concurs with the ‘missing pieces’ argument.
“The form doesn’t cover all cyber threats. For instance, insider threats from individuals within the organization with access to sensitive systems aren’t directly addressed.
“Additionally, supply chain attacks that exploit vulnerabilities in third-party components require separate attention. Finally, emerging technologies such as quantum computing and AI present new challenges that may exceed established security practices outlined in the form.”
How Software Suppliers Can Meet the Requirement
Every new regulation presents a regulatory hurdle to businesses. Given that partnerships with the U.S. Federal government are at stake, businesses will need to gear things up to meet the requirements lined up in the attestation form.
Speaking to Techopedia on the way forward for software suppliers, Dr. Harry Wang, VP of Strategic Partnerships at Sonar, recommends that organizations should start by having different environments for developments and products.
Dr. Wang said:?
“Separate production and development environments, better code quality, enforced multi-factor authentication, encryption, and, importantly, continuous monitoring/testing of code — these are all ways companies can ensure better security in their software.”
Since the attestation form clearly outlines the specific security practices that will be assessed, Wang pointed out some best practices he believes would steer software providers toward these secure practices.
“By adopting a more secure production environment, memory-safe programming languages, Clean Code principles, and continuous code quality analysis to reduce tech debt, developers can prevent security incidents, reduce risk exposures, and improve the availability of their applications.
“This becomes increasingly important as we expect the volume of code produced to increase with the use and innovation of AI code assistants.”
For Loveland, keeping software secure is more than just meeting the demands of CISA through an attestation form.
“Software makers must recognize that more than compliance with the given form is required to secure their products, infrastructure, and customers from cyber threats. They must integrate this form into their best practices to protect their systems against intentional and unintentional attacks.”
The Bottom Line
CISA’s attestation form is a crucial first step in ensuring the security of software development processes as well as protecting the U.S. Federal Agencies from supply chain attacks.
The stipulations in the form embody essential practices for secure software development that vendors aiming to market software to the Federal Government should be prepared to fulfill if they wish to play in the federally regulated ecosystem.
It behooves software suppliers to look inward, determine where they’re lacking in terms of security best practices, and imbibe a security culture that increases their chances of meeting the requirements laid bare in the form.
