Software supply chain attacks are rife - this is what developers need to watch out for

Software supply chain vulnerabilities are being pounced on by threat actors at record pace, and as a result developers need to improve their security and prepare for attacks, according to new guidance from a leading industry body. 

Sophisticated attacks on software have taken place after hackers targeted various points of the software development life cycle (SDLC), said the US National Institute of Standards and Technology (NIST), which has set out the potential risks and some mitigations in a new report.

“Such attacks are also stealthy because they typically propagate through legitimate channels, such as software updates, which allows for widespread damage to users of the target software. These attacks are successful because of the significant amount of implicit trust present in these legitimate channels”, the NIST report said.

Cloud applications are made up of many smaller connected elements called microservices. These are generally developed through an Agile process known as DevSecOps, which uses Continuous Integration/Continuous Delivery (CI/CD) pipelines to manage production.

It’s this aspect of the software supply chain that is coming under increasing scrutiny, NIST warned.

That’s because hackers are increasingly attempting to subvert software pipelines to their own ends, for example by injecting their own code - like crypto miners – or by introducing flaws that can be used as backdoors to target users.

The software supply chain is a ripe target for hackers

Software supply chain attacks are appealing to attackers because they potentially allow attackers to sneak in through less secure but trusted channels to create a lot of damage in a short period of time.

NIST said the security of each individual activity in the software supply chain is “paramount” for the safety of the resulting software, but many activities are overlooked from a security point of view, such as writing source code; building, packaging, and delivering an application; and repackaging and containerization.

Attackers can come in the form of external groups such as state-backed hackers or criminals, but could also be disgruntled employees or contractors, NIST warned.

Indeed, internal attackers pose a significant risk, as they may have insider access to sensitive information — often using legitimate access rights — that allow them to launch attacks or steal confidential information.

Either group could use techniques such as phishing, malware, social engineering, and physical access to systems and companies should be aware of these risks and take appropriate measures, NIST said.

In particular, developer workstations and their environments “present a fundamental risk” to the security of a software supply chain and should not be trusted as part of the build process since they are at risk of compromise, NIST added.

Attacks might come in the form of malware attacks on developer workstations, social engineering attacks on developers, attacks on the development environment, and physical attacks on the hardware or networks used by developers.

All these different potential attacks will need to be defended against differently, with endpoint protection software, network security controls, access control policies, and physical security measures.

Attackers may also attempt to introduce vulnerabilities, malware, or stolen credentials to gain access to other systems or compromise sensitive data. For example, attackers may fork a repository, then initiate a pull request to merge the forked project – with added malicious code - with the original project.

“If the project maintainer accepts the request without properly and adequately reviewing the changes and determining them to be suitable, they will merge them into the original project, thus introducing malicious code into the repository,” NIST warned.

When open-source code is used, a package is often pulled from a repository based on the reputation of the developer or the repository.

“However, there is no guarantee that pulled code is the same software that the developer authored and checked into their source code repository,” the report said.

NIST said security teams should approve the merging of unverified sources of open source software, that developers should download open source as source code rather than pre-compiled libraries or binaries, and should verify digital signatures, run vulnerability scans, and check for recent updates on newly downloaded source-code.

It listed some of the various controls companies could use to mitigate risks to their SDLC environment. These include:

• Regular patch management
• Robust authentication
• Granular authorization
• Malware protection
• Secure SDLC practices
• Data protection measures
• Physical security controls
• Auditing and monitoring tools

NIST said CI/CD processes should be audited regularly, and automation should be introduced wherever possible.

There should be isolated CI/CD environments and elevated administrator credentials for the deployment of applications in clouds, and enhanced real-time monitoring and alerting mechanisms to detect suspicious activities in CI/CD servers - especially activities that might indicate the exfiltration of sensitive data or the tampering of builds.

Software supply chain security can’t be rushed

Henrik Plate, who leads the research team at software supply chain security startup, Endor Labs, said one thing that stands out in the document is the emphasis on the definition of roles and, closely related, the identification of granular authorizations for user and service accounts. 

“This is necessary to implement access controls for all activities and interactions in the context of CI/CD pipelines according to least-privilege and need-to-know principles. However, the management of all those authorizations across the numerous systems and services invoked during pipeline execution can be challenging,” he said.

Plate said it was not surprising that the NIST document acknowledges that the steps needed for software supply chain security cannot be implemented all at once in the SDLC of all enterprises without a great deal of disruption to underlying business processes and operations costs.

Activities mentioned in the document such as the scan of dependencies for known vulnerable versions and malware are absolutely crucial, he added, and need to be performed during pipeline execution.

“Beyond that, however, organizations need to implement broader management of open source dependency risks, which does not only search for the presence of such defects (after the fact), but anticipates open source risks more proactively, e.g. using risk indicators like the quality of code, project liveliness or others. Implementing a more holistic open source risk management reduces both security and operational risks.”