The U.S. Cybersecurity Infrastructure Security Agency (CISA) recently released new guidance on its Secure by Design principles, outlining best practices that the IT sector should take to reduce the cyber-risks its products are exposing its customers to.
Insecure code is being released by software firms, cloud providers, hardware manufacturers, and others, amplifying risk across the entire digital economy. CISA's IT Sector-Specific Goals (SSGs) provide a definitive set of 18 of the most relevant application security (AppSec) and product security best practices meant to minimize risk.
The best practices, arrived at through a joint effort between CISA and a coalition of subject-matter experts from the IT Sector Coordinating Council (IT SCC), include what they agree are the practices most likely to help bring to maturity Secure by Design practices in the IT and product design world. “They were developed based on CISA’s operational data, research on the current threat landscape, and in collaboration with government, industry groups, and private sector experts,” CISA wrote in its publication of the SSGs.
Some of the suggestions are sweeping goals that will take a long time to achieve. Others are likely within reach for most cybersecurity programs — the obvious improvements that many companies just haven’t gotten around to putting into place.
Here are seven key highlights from the SSG guidance that your organization should take action on.
[ Get our Essential Guide: Software Supply Chain Security for Dummies ]
1. Double down on multifactor authentication
On the product design side, the first goal is to get IT departments to increase the use of phishing-resistant multifactor authentication and to push for its use in software products. Part of those efforts should include what CISA calls "seat belt chimes" to nudge users to turn MFA on. “This could include banners or interstitials notifying users or administrators MFA is not enabled,” CISA wrote.
CISA also urged organizations to require their developers to use MFA when authenticating into development environments.
2. Harden your development environment
Several suggestions in the guidance involve bringing greater security discipline and controls over the systems that developers use. For example, the guidance advocates for better network segmentation by separating all environments in software development. Additionally, the goals urge IT-sector firms to regularly log, monitor, and review trust relationships and access controls in dev environments.
More fundamentally, CISA said that development organizations need to do a better job of vetting and hardening the tools they use in their development tool chains. This addresses major concerns that software supply chains can be tainted from the get-go if attackers take control of the developer stack.
3. Stop hardcoding credentials and secrets into source code
In addition to the IT SSGs, CISA last month released an update to its Product Security Bad Practices document that works hand in hand with the SSGs by laying out some of the worst practices that are hindering Secure by Design efforts. One new worst practice is hardcoding credentials. Unsurprisingly, CISA urged IT firms to stop including credentials and other secrets in their source code.
“It advised firms to store sensitive data and credentials in an encrypted manner, such as using a secrets manager, and added that the firms should also securely store and rotate SSH keys.
4. Provide SBOMs to customers
CISA has been at the vanguard of championing the use of software bills of materials (SBOMs) in order to drive better visibility and control over software supply chain risk. Little surprise, then, that its best practices include IT firms consistently providing their customers with SBOMs for each of their products so customers have clear documentation of what components are included.
5. Be proactive about software flaw reduction before release
A number of both development and product design goals center on vulnerability reduction. A very prominent once is that firms scan source code through automated tooling to find and mitigate known vulnerabilities before each release.
It also advocates tying release triggers to remediation and proactively seeking to eradicate across their software portfolios whole classes of high-risk and easily avoidable vulnerabilities, such as SQLi and XSS flaws. CISA also urged transitioning to memory-safe languages to reduce flaws on that front.
6. Improve transparency and communication about vulnerabilities
Another major goal in the SSGs is more transparency and better communication of vulnerabilities. At the foundation of that is the suggestion that companies need to have a vulnerability disclosure policy in place.
“Publish a vulnerability disclosure policy (VDP) that authorizes testing by members of the public on products offered by the manufacturer, commits to not recommending or pursuing legal action against anyone engaging in good faith efforts to follow the VDP, provides a clear channel to report vulnerabilities, and allows for public disclosure of vulnerabilities in line with coordinated vulnerability disclosure best practices and international standards,” CISA recommended.
Related to that is a call to provide detailed Common Weakness Enumeration (CWE) and Common Platform Enumeration (CPE) in every Common Vulnerabilities and Exposure (CVE) that the firms release.
7. Establish a software supply chain risk management program
Finally, CISA strongly stated that IT-sector firms need to get serious about software supply chain security by establishing a formal program to tackle these risks. These programs should be designed to integrate supply chain risk management practices directly into the SDLC, including regular code testing and auditing of supply chain risks.
One of the more significant aspects of recent federal guidance on software supply chain security from the Enduring Security Framework (ESF) is the recommendation of binary analysis and reproducible builds as best practices.
The document, titled "Securing the Software Supply Chain: Recommended Practices for Managing Open-Source Software and Software Bill of Materials," builds on previous efforts by the U.S. federal government to foster formal standards for bolstering software security against current and emergent threats, including the most recent push for Secure by Design, which seeks to shift liability for software compromises to software teams.
Saša Zdjelar, chief trust officer at ReversingLabs, said the recommended use of binary analysis and reproducible builds marks a significant step forward in ensuring better software supply chain security. AppSec practices such as static application security testing (SAST) and dynamic application security testing (DAST) typically apply only to a small subset of internally developed systems and applications at many organizations, he said.
Legacy application security testing is out of sync with modern software development because it does not cover software developed by commercial providers and other third parties, Zdjelar stressed.
"Our ability to analyze binaries is key to understanding risk in third-party software."
—Saša Zdjelar
