Vet third-party apps to reduce supply chain threats
Enterprises are more vulnerable than ever before to supply chain threats from third-party apps and modules. Last fall's compromised NPM package is one cautionary tale.
Most enterprises already have a difficult time handling risk, and as enterprises dig further into the supply chain and the components used to run their operations, managing supply chain threats is becoming even more of a task. Software development is among the most challenging.
The first step in reducing your exposure to risks is to identify the scope of the systems and components affecting your enterprise. This may include identifying third-party software modules that should be part of risk assessment processes and secure software development practices.
In this tip, we'll look at the deployment of third-party software modules in the enterprise and steps companies can take to reduce the likelihood of trouble.
Using third-party software modules in the enterprise
Most enterprises have a large inventory of custom-developed, integrated, open source and commercial software -- each with its own dependencies and supply chain. These dependencies are necessary, but they don't get much attention until there is a problem.
Case in point: there was last fall's update to the event-stream Node Package Manager (NPM), which included cryptocurrency-stealing code, and which wasn't revealed until almost two months after the software was released. There have also been prior security issues identified in NPM packages.
Jarrod Overson blogged about investigating the event-stream NPM package. The event-stream developer changed ownership of the project and the cryptocurrency-stealing code was added by the new developer in a subsequent update. The original developer hadn't used the module in years and agreed to give a new developer control of the package.
Once the malicious code was added, the developer updated the version information so applications that used the module would install the updated version. The package was installed as a dependency to other modules and was reportedly downloaded two million times per week. NPM packages will follow best practices to determine if updates to dependencies are available and auto-install the updated modules, making these types of attacks difficult to combat.
The event-stream module appears to have been targeted because it is used by Copay, an application that manages bitcoin for users and groups. Making this attack even more challenging to pinpoint, the event-stream NPM package was lumped in with other NPM packages as a dependency to developers' existing supply chains. The developer may not even have intentionally installed the package and it may have been installed by a separate package that had it as a dependency.
Finally, event-stream NPM is open source, which could have made it easier for an attacker to gain access to the source code and push updates. Open source software is more vulnerable to attack because it may not have resources sufficient enough to ensure security.
Steps enterprises can take to manage third-party software modules in the enterprise
The first step to manage third-party software modules in the enterprise is to identify the modules in use in the supply chain. These potential supply chain threats should include the open and closed source code included in software developed internally or externally. Policies and procedures, set by the security team, should be used to vet code with software developers. Security engineers should also provide the oversight needed to help the development team conduct the reviews.
In the NPM incident, if the update had been reviewed by enterprises prior to its installation, it's likely the malicious code would have been identified and investigated before the software was put into production.
Once all the application modules have been identified, each component must be vetted in the same way it would be if the software had been developed internally. When a component is updated, it should be checked to identify the change. Depending on the company's risk tolerance, updates can either be assessed as if they are entirely new code or they could be subject to a less rigorous review -- where only the changed code is examined.
In the NPM incident, if the update had been reviewed by enterprises prior to its installation, it's likely the malicious code would have been identified and investigated before the software was put into production.
Module vetting should start at the software project level, and it should include information about how the project is managed. A module developed by a lone developer -- even if it is a component of a well-supported project -- may offer substantial benefits, but it could also pose challenges for long-term maintenance and support. It is important to consider the potential risks prior to deployment. One critical concern is assessing how security for the modules is integrated into the software development lifecycle.
One approach to mitigate supply chain threats is to investigate software development security using the Building Security In Maturity Module. This would include reviewing the documentation, the policies and the code itself. It may even consist of using software security tools to analyze the source code or the binaries being used. This could include static code analysis or dynamic code analysis tools.
Source code assessments can be conducted either manually or automatically. The latter may be easier to perform for open source code because the source is available. For closed source code, the team may need to work with the original developer to assess the security of the code and perform dynamic analysis of the binary.
All of these steps are very resource-intensive; evaluating each individual module may be too big of a challenge for most enterprises. Instead, companies may want to consider using automated tools to perform these tasks or using trusted software repositories.
Third-party modules can offer enterprises a significant number of benefits, but they can also pose supply chain threats. Managing these dependencies is complex, but it's important to monitor and oversee all the changes made in software development -- including third-party code in your supply chain -- to ensure your operation is secure.
