The Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute for Standards and Technology (NIST) released new guidelines on defending against various software supply chain risks.
Software supply chain attacks occur when threat actors infiltrate vendors’ infrastructure and infect software before the vendor sends it to their customers. Additionally, malicious actors could deliver compromised software after distribution through compromised updates channels.
CISA and NIST advised software vendors and organizations to adopt listed mitigations to avoid supply chain attacks and remain resilient during successful exploits.
NIST and CISA say software supply chain attacks pose severe risks
The agencies noted that software compromised through supply chain attacks could have “widespread consequences for government, critical infrastructure, and private sector software customers.”
Such software could allow threat actors to circumvent cyber defenses for initial access, maintain persistence, exfiltrate data, and carry out cyber espionage.
Software supply chain attack techniques
The agencies listed update hijacking, tampering with code signing, and the compromise of open-source code as the popular methods used by hackers to compromise software.
Threat actors hijack update channels, like in the Russian NotPetya attack on Ukraine via tax accounting software. The SolarWinds Orion software supply chain attack employed similar tactics.
“What would later be called the NotPetya malware spread well beyond Ukraine and caused major global disruptions in crucial industries, including international shipping, financial services, and healthcare.”
Some threat actors like the Chinese APT 41 replace code signing certificates with self-signed certificates to target victims in the United States and other countries.
“Attackers undermine codesigning by self-signing certificates, breaking signing systems, or exploiting misconfigured account access controls,” the guideline stated.
Attackers also inject malicious codes into public code repositories to trick unsuspecting developers into downloading compromised software.
For example, researchers discovered twelve malicious Python libraries uploaded to the official Python Package Index (PyPI) site. The threat actors used typosquatting tactics to spoof popular libraries such as “diango,” “djago,” or “dajngo” for Django.
NIST and CISA noted threat actors must have the intent and capability to carry out software supply chain attacks because of the sophistication level and time required.
Mitigating software supply chain attacks
The agencies said that defending against software supply chain attacks was particularly difficult because third-party applications usually require administrative permissions. Most customers also accept software defaults without investigating the necessity for elevated permissions.
Additionally, the applications regularly communicate with the vendors’ domains to download updates for additional functionality and bug fixes. However, the update channels might be compromised through software supply chain attacks like the SolarWinds Orion software.
The interagency report made several recommendations for software vendors and organizations to avoid becoming victims or launchpads for software supply chain attacks.
They advised organizations to use software in the “context of a risk management program” as a general precaution.
The agencies also recommended using NIST’s Cyber Supply Chain Risk Management (C-SCRM) framework and the Secure Software Development Framework (SSDF) to identify, assess, and mitigate risks.
The directive listed several actions that organizations could take to avoid the acquisition of compromised software, mitigate deployed compromised or vulnerable software, and increase resilience after a successful exploit.
They also advised software vendors to implement the software development life cycle (SDLC) in their business processes.
NIST, however, warned that “[f]ew [SDLC] models explicitly address software security in detail, so secure software development practices usually need to be added to each SDLC model.”
Developers should avoid supplying compromised software by implementing SSDF in the context of secure development infrastructure. They should also follow a risk-based approach to development activities, according to NIST and CISA’s guidelines.