Michael Edenzon
January 20, 2025
•
8
min read
On January 16, in the final days of his administration, President Biden issued an executive order aimed at strengthening the nation’s cybersecurity defenses. The President addresses the technology industry’s most imminent challenges, including artificial intelligence, quantum encryption, IoT devices, and cloud security. Most notably, the order signals a new direction for software supply chain security. The latest directive appears to be a tacit acknowledgement that significant challenges in software development and governance remain unresolved, over three years after the outgoing administration’s first cybersecurity order. Two key elements stand out: the requirements for software attestations and the pilot program for a rules-as-code approach. Both are laudable in intent, but their implementation reveals significant gaps that could undermine their effectiveness.
The most significant addition to the administration's cybersecurity approach is the concept of attestations. A software attestation is a formal, evidence-backed declaration pertaining to the origins, development, or build processes of a software artifact. In other words, it’s a claim that details when, where, or how a given software was built.
The executive order mandates that software providers to the federal government must provide machine-readable attestations affirming their adherence to secure software development practices. These attestations must be accompanied by evidence to support their claims, in what the directive describes as “high-level artifacts.” The Cybersecurity and Infrastructure Security Agency (CISA) has been tasked with developing a system for collection, verification, and management of attestations through a centralized repository. The order further stipulates that attestations will be subject to “validation,” the outcome of which will become public record. If a software provider’s claims cannot be validated, CISA will notify the provider and could elect to escalate the matter to the Attorney General.
Additionally, the executive order calls for a pilot program to establish a rules-as-code approach. This initiative envisions cybersecurity policies and regulations being translated into machine-readable, executable formats. The goal is to create a system where rules can be programmatically enforced, reducing ambiguity and improving consistency in how policies are applied.
The inclusion of attestations signals an acknowledgment of the critical role software supply chain security plays in national cybersecurity. The intent is to compel software providers to not only adopt secure practices but to prove it. This is in line with the broader industry movement toward frameworks like Supply Chain Levels for Software Artifacts (SLSA), which provide a roadmap for verifying the integrity and security of software components.
This approach is also a direct response to high-profile breaches like SolarWinds, where attackers exploited weaknesses in the software supply chain to compromise government and private organizations. SolarWinds taught the industry that trust in software cannot be assumed; it must be earned and continuously validated. Attestations, if implemented correctly, could serve as a linchpin for rebuilding this trust.
Similarly, the rules-as-code pilot program reflects an evolution in how policy is operationalized. The concept of converting rules to machine-readable code is referred to in the software industry as “Policy-as-Code” or “Automated Governance,” and has been a focus of the DevOps movement since 2019, with the goal of improving compliance efficiency by ingesting regulatory requirements directly into software delivery systems to receive real-time feedback on compliance status. This isn’t just a vision for the future; it’s a necessary step to keep pace with the complexity and scale of modern software ecosystems.
However, the executive order falls short in key areas. Most notably, while it emphasizes machine-readable attestations, it conspicuously omits any mention of machine-generated attestations. This distinction matters.
Machine-readable formats ensure that attestations can be parsed and understood by automated systems, but if the attestations themselves are not machine-generated, software providers remain reliant on human processes to create them. This introduces variability and increases the risk of errors, omissions, or even intentional misrepresentation.
A better approach would require attestations to be automatically generated as part of the software development and delivery pipeline. Tools that integrate directly into CI/CD workflows could produce attestations in real-time, ensuring they are both accurate and reflective of current practices. This would align with the principles of SLSA and create a stronger foundation for trust.
The rules-as-code initiative also leaves much to be desired in terms of specificity. The executive order doesn’t address how these coded rules will be maintained, updated, or made interoperable across different systems. Nor does it consider the significant challenge of translating complex, often ambiguous policy language into precise, executable code. Without clear guidance, the pilot program risks becoming a proof of concept that never achieves practical adoption.
When it comes to attestations, the obvious is this: if secure practices are being followed, there should be proof. Attestations—backed by affirmative, verifiable evidence—should not be a burden but a natural byproduct of a well-governed development process. If it’s done, show the proof.
But the inconvenient truth is that not all proof is created equal. As I’ve argued before, good proof is comprehensive, contextual, and defensible. Bad proof—incomplete, ambiguous, or easily fabricated—undermines the very trust it seeks to establish. By not mandating machine generation of attestations, the executive order leaves the door open for bad proof to proliferate.
The same principle applies to rules-as-code. The obvious benefit is the ability to automate compliance checks, reducing the need for subjective human interpretation. But the inconvenient challenge lies in ensuring that these coded rules accurately capture the intent of the original policy. This requires collaboration between policymakers, technologists, and industry experts, as well as robust mechanisms for testing and validation.
To close these gaps, we need to move beyond the minimum requirements outlined in the executive order and embrace a more ambitious vision for automated governance:
Providers should integrate tools into their pipelines that automatically generate attestations at every stage of the software lifecycle. These attestations should be tied to specific evidence, such as test results, code scans, and configuration checks, creating a chain of trust that is both auditable and tamper-resistant.
Fianu offers 30+ attestations out of the box, covering both security and quality assurance. With over 60 integrations your developers can continue to use their existing tools. Fianu will produce the evidence.
CISA, NIST, and OMB must work together to define standardized formats for attestations and artifacts, ensuring interoperability across systems and minimizing the burden on providers.
The in-toto project is the leading open source specification for software supply chain attestations. Fianu attestations are fully compatible with in-toto, and provide a host of tools that allow development teams to start generating attestations in minutes.
The pilot program should prioritize building an open, extensible framework for translating and executing rules. This includes creating libraries of reusable rule components and tools for validating their accuracy against policy intent.
The Fianu platform includes over 30 out-of-the-box “rules-as-code” that can be leveraged to generate attestations, audit trails, and real time compliance monitoring.
The executive order is a step in the right direction, but it’s just the beginning. To truly secure our software supply chains, we need to go beyond what’s easy or obvious and confront the inconvenient complexities head-on. This means demanding better proof, embracing automation, and holding ourselves accountable to the highest standards of transparency and integrity.
Schedule a demo today!
