Software companies that sell to the US government suddenly face a number of additional hurdles when it comes to developing and maintaining their software solutions due to increased regulation, primarily focused on security. But the number of cybersecurity incidents reported by US federal agencies has remained fairly constant (~30K-35K incidents) every year since 2016, so why the push for greater regulation now? 

Cybersec Incidents

Source: Statista (Note: the decrease in reported incidents from 2015 to 2016 is likely due to a change in federal incident reporting guidelines)

The problem is that not only are software vulnerability exploits growing, there’s also been an exponential growth in software supply chain attacks that represent a new vector for cyberthreats to US government systems:

  • The Solarwinds Orion security software hack affected multiple departments across the US government, including the armed services (2020).
  • The Colonial Pipeline ransomware attack disrupted fuel delivery to the US East coast (2021).
  • A Microsoft Internet Information Services (IIS) vulnerability was targeted at a US federal agency in order to install malware (2022).
  • Pentagon cyberattacks compromised 632,000 employee email addresses (2023).

And countless others aimed not just at the US government but other governments as well, worldwide. Given that the onus for preventing software supply chain attacks rests with ISVs, it makes sense to try and make them the first line of defense for securing the software the US government relies on. This has resulted in two primary requirements for ISVs:

  • Aligning software development practices with the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) 
  • Verifying that you are aligning with a subset of SSDF requirements by filling in the Cybersecurity and Infrastructure Security Agency (CISA) Attestation form. 

CISA Attestations For ISVs

The SSDF specification requires that ISVs undertake what is likely to be a multi-year implementation impacting multiple stakeholders across the enterprise, as well as involving quite a few new and/or changes to existing processes and controls in order to become compliant. 

The good news is that the CISA Attestation requires only a subset of SSDF requirements to be implemented before an ISV can attest “in good faith” that they are aligned with the US government’s requirements. The bad news is that implementing the subset is a non-trivial undertaking for organizations that aren’t already prioritizing security.

In brief, the CISA Attestation requirements include:

  • Development Environment Security: developer desktops, code repositories and CI/CD systems must be implemented with secure controls to ensure code is being developed, checked in/out and built in a manner that minimizes risk.
  • Software Supply Chain Security: implement controls to ensure the security and integrity of open source and other third-party software.  
  • Code and Artifact Provenance: create and maintain provenance in order to validate that software artifacts have been sourced and built securely.  
  • Vulnerability Remediation: identify, disclose and remediate vulnerabilities in a timely manner depending on risk level.

In some cases, there are a number of best practices that you may already be employing which can help attest to your compliance with these requirements. In other cases, closing the gaps may need significantly more work to meet the requirement set by CISA.

How ActiveState Can Help With CISA Requirements

The ActiveState Platform is a SaaS solution that is designed to be integrated with any software development process in days, not weeks. This can allow you to meet CISA Attestation requirements more quickly and easily than implementing them yourself.

For example, consider the first CISA requirement #1: the software is developed and built in secure environments. This means you’re on the hook for standard best practices like:

  • Logging, monitoring & auditing authorization and authentication checkpoints.
  • Enforcing Multi-Factor Authentication (MFA).
  • Preventing leakage of secrets, credentials and other sensitive information.

But it also means minimizing the risk of attack vectors being exploited in each environment, such as the hack suffered by Solarwinds in their Orion software build environment. 

The ActiveState Platform provides you with a hardened, tamper-proof build service designed to build all your components from source code in a reproducible manner. Hashes are validated at each build step, and the build discarded on mismatch. This eliminates attack vectors like build script tampering and dynamic inclusion of remote resources during build steps, among others. 

ActiveState’s secure build service also helps with CISA requirement #2: maintain trusted source code supply chains by employing automated tools. 

Most organizations today rely on binary scans of prebuilt open source components that form the vast majority of their software supply chain. However, binary scans can be problematic for a number of reasons. In contrast, the ActiveState Platform will automatically build the open source your projects require from vetted source code, eliminating attack vectors like typosquatting, dependency confusion, malware, and so on. 

One of the key outputs of ActiveState’s build process addresses CISA requirement #3: create and maintain provenance for third-party components. 

Provenance reflects the trustworthiness of the components used to build your software: were they acquired from a legitimate source, built in a secure manner, and not tampered with? To that end, ActiveState provides Software Attestations, which are a key way for ISVs to establish trust for their software by offering customers a way to independently validate the security and integrity of their applications:

  • Provenance Attestations provide metadata about where the component was sourced from, and how it was built.
  • Verifiable Summary Attestations verify the security and integrity of built artifacts as measured against Secure Levels for Software Artifacts (SLSA) Build Levels.

Lastly, the ActiveState Platform can also help with CISA requirement #4: automated tools that can identify, disclose and address security vulnerabilities in a timely fashion. 

Key capabilities provided by ActiveState include:

  • Providing warnings and email notifications when open source components are found to be vulnerable, thereby reducing Mean Time To Identification (MTTI).
  • Providing a live dashboard view of all open source components and their CVEs currently deployed in all environments for all projects.
  • Enabling users to select fixed versions of vulnerable components, and automatically rebuild a non-vulnerable runtime environment, decreasing Mean Time To Remediation (MTTR). 

Conclusions: Meet CISA Requirements Faster

Meeting CISA attestation requirements is key to ISVs gaining and keeping lucrative US government contracts. But complying with those requirements can be both time and resource intensive, diverting attention from creating innovative software to implementing processes, procedures and tooling. 

Solutions like those from ActiveState can help bridge the gap between current capabilities and CISA requirements by providing an easy-to-implement solution that addresses many of the most essential features. 

Next Steps

The CISA requirements are just a subset of the more complex – and complete – set of requirements for the Secure Software Development Framework. Read how ActiveState can also help you meet SSDF requirements.