CISA’s guides can help you demand – and receive – secure software from the get-go

Your team is in charge of identifying and procuring new software for your firm, so you check out the options in the marketplace, read reviews, and test the software. But how do you know it’s secure?

Not a day goes by that there isn’t an incident reported that reminds us that we’re only one vulnerability away from becoming a news headline or having to make an SEC filing. So how can we demand more from our vendors and get software that is secure by default?

A good place to start is with the US Cybersecurity and Infrastructure Security Agency (CISA), which has recently released several guides designed to assist in the acquisition and use of software and related products in an enterprise environment.

These documents flow from CISA’s overall Secure by Design initiative, providing recommendations drafted in consultation with the FBI and numerous national security services from the UK, Canada, Australia, Norway, Japan and many other countries, that can help us understand and address the risks associated with purchasing software.

The CISA Software Acquisition and Secure by Demand guides

CISA’s Software Acquisition Guide addresses the cybersecurity risks associated with buying software and the Secure By Demand Guide lays out how customers can query software manufacturers to understand how their products have been designed with security in mind.

Even if you are not bound by either document, I’d argue that you need to review the questions and points made in the whitepapers. Your vendors may not have documented answers for all of the questions, but the general idea is that we are all working to ensure that the software we purchase is free from known vulnerabilities, backdoors, and other issues that may turn into security issues down the road.

The Software Acquisition Guide document is divided into five primary sections, each with its own set of control questions and clarifying tasks:

• 19 for supplier governance and attestations.
• 8 for software supply chain.
• 30 for secure software development.
• 12 for secure software deployment.
• 8 for vulnerability management.

As the guide outlines, some of these questions can be skipped if the supplier provides a CISA Secure Software Development Attestation Form, or equivalent such as the GSA 7700 Secure Software Development Attestation Form, without the need for a Plan of Action and Milestones.

CISA’s guidance doesn’t just work for government agencies

But even if you’re not a government agency, it’s helpful to review the questions on both the Software Development Attestation and GSA 7700 forms, to see if your vendor can answer them.

These questions go right to the heart of security concerns. Is the software developed to support using multifactor authentication? Does the vendor protect access to the developer infrastructure, as well as making a good faith effort to use and maintain a trusted source code and supply chain? Do you know if the software vendor used open-source components in their development and understand who has contributed to the code? Does the developer regularly review and patch software used to develop software used to develop software?

It makes sense that a vendor’s development platform should be as secure as possible to ensure that malicious actors can’t target it.

Asking questions like these can determine whether vendors undergo a penetration testing or fuzzing process to ensure that the software they’re building is secure. Do they have a process to be notified of bugs and other issues from external sources?

It’s certainly in your best interest to know before you buy whether a vendor is protecting vulnerable components in their own environment, regularly consulting the DHS CISA Known Exploited Vulnerabilities (KEV) Catalog and patching, rebuilding, or otherwise mitigating known threats.

Encouraging good vendor communication and disclosure

Better vendor communication is also an important outcome of following the CISA guides — is the seller reporting known vulnerabilities to you in an industry-standard manner, indicating risk levels and communicating alternative mitigation techniques? All vendors should provide resources that you can use to protect yourself if you can’t install an update immediately — risk factors should be communicated in a manner that is easily understood and easily converted for your environment.

The CISA guidance is geared toward driving more clarity from suppliers as to whether they are using a secure-by-default approach for the software deployment processes and following known secure design principles.

If a vendor is using third-party components in its products, do they do their due diligence on them or merely download the latest recommendation from GitHub without reviewing the source and who committed to the project to fix an issue with their software?

Does the supplier provide a formal, machine-readable inventory of software components and dependencies and information about those components and their hierarchical relationships? These inventories should be comprehensive — or should explicitly state where they could not be provided.

These questions are not nice-to-know; they are need-to-know. Software bills of material (SBOMs) may include open-source or proprietary software and can be widely available or access-restricted. This document is more likely to be delivered if you specifically include this in your software contract from the beginning of the engagement. If these items are not in your existing software contracts, review and revise them as needed to build in these necessary security mandates.

As more and more software is impacted by artificial intelligence, ensure that you go back to your existing software contracts and include guidance and wording to define the scope and use of AI in your software. Plans for future use of AI should be discussed and documented by the software vendor.

It’s critical for customers to demand more security from vendors

The Secure by Demand guide reminds us that all enterprise software consumers can demand that product security considerations be integrated into various stages of the procurement lifecycle. As they note, all of us can perform the following tasks:

• Before procurement, pose questions to understand each candidate software manufacturer’s approach to product security.
• During procurement, ensure that product security requirements are integrated into contract language as appropriate.
• Following procurement, continually assess a software manufacturer’s product security and security outcomes.

Start by asking your vendors if they have taken the CISA Secure by Design Pledge and what they’ve communicated about their progress and commitment to security. Have they made it easy to install security patches and perform mitigations? Is there the ability to install and manage security issues easily and automatically?

Good security from the get-go beats adding it later

Just as a baseline, companies you buy software from should support secure authentication, applying modern techniques ranging from single-sign-on to multifactor authentication and ensuring they support phishing-resistant authentication. Most importantly, has the software vendor removed default passwords or are they in the process of eliminating their use in all of their product lines and communicating this process?

We have used software for years that has been subject to such vulnerabilities as SQL injection attacks, weak cryptography, and cross-site scripting (XSS) attacks, to name a few. Let’s push for good vendor communication around whether they’re working on removing specific types of defects from their software that allow these attacks.

In addition, review whether your vendors are planning to move to memory-safe languages. Vendors should move to programming languages such as Rust, Go, C#, Java, Swift, Python, and JavaScript. These languages prevent certain types of memory-access bugs and improve software security.

Next, ensure that your software vendors include basic logging in the software you own and that it tracks categories such as configuration changes, identity logins, network flows, data access, and creation of business data. These logs must be accessible and readable in your software.

We can no longer rely on adding security at a later date. Software needs to be designed from the start to have these security features. Review these documents and see if your vendors can respond affirmatively to the concepts discussed.