“Advancing progress toward a technology environment where all software products are safe and secure by design is a top priority for the U.S. Cybersecurity & Infrastructure Security Agency (CISA), the broader U.S. government, and the global cybersecurity community.”
Before we look further into some of the self-attestation requirements, let’s look at some of CISA’s cybersecurity concerns. According to the CISA, the common methods of compromise used against software supply chains include exploitation of software design flaws, incorporation of vulnerable third-party components into a software product, infiltration of the supplier’s network with malicious code prior to the final software product being delivered, and injection of malicious software that is then deployed by the customer. They are also concerned with other vulnerabilities and the potential for compromise:
Undocumented features or risky functionality
Unknown and/or revisions to contractual, functionality or security assumptions between evaluation and deployment
Supplier’s change of ownership and/or of geo-location
Poor supplier enterprise or development hygiene.
The government is most concerned with the security and integrity of critical software they define as software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources). More specifically, they define critical software as software that:
Is designed to run with elevated privilege or managed privileges
Has direct or privileged access to networking or computing resources
Is designed to control access to data or operational technology
Performs a function critical to trust
Operates outside of normal trust boundaries with privileged access
To help mitigate these risks, the CISA has developed a self-attestation form that software developers serving the US Government must conform to.
This self-attestation form identifies the minimum secure software development requirements a software producer must meet, assuring that software they produce was developed in conformity with specified secure software development practices.
The software was developed and built in secure environments.
The software producer has made a good-faith effort to maintain trusted source code supply chains.
The software producer maintains provenance data for internal and third-party code incorporated into the software.
The software producer employed automated tools or comparable processes that check for security vulnerabilities.
The software self-attestation initiative is expected to go into effect later in 2023.
If you are an ISV and this forthcoming government initiative applies to you, I recommend that you speak with the software security experts at Wibu-Systems. While our CodeMeter software licensing and protection technology does not address all of the security requirements listed, our Wibu Academy can help identify areas where our secure software development practices can help in tandem with your own security measures.
You can also browse through our software security resource center and learn more about our CodeMeter solutions with white papers, case studies, tutorials, use cases, and more.
Co-founder of WIBU-SYSTEMS AG, President and CEO of WIBU-SYSTEMS USA
Marcellus Buchheit earned a master's degree in computer science from the University of Karlsruhe, Germany, in 1989, the same year he co-founded Wibu-Systems. He is known for designing innovative techniques to protect software from reverse-engineering, tampering and debugging. He frequently speaks at industry events and is co-author of the IIC's Industry IoT Security Framework publication. He is currently president and CEO of Wibu-Systems USA, Inc. based in Edmonds, Washington State.