What’s hiding in your code?

Even simple projects have a way of ballooning quickly and that tendency is amplified by the ease of incorporating existing pieces of code or node libraries.

It is still somewhat manageable when you are the only one writing that code, but it becomes harder when code is written by a number of developers and teams, as is the case normally.

Even the team lead, the one in charge of approving all pull requests, can not know every line of code, every function, and every variable.

An issue of trust

That’s one of the reasons the minor code change that took place in the Orion app in late 2020, in the case later known as SolarWinds, went undetected for so long. The entire change was only a few dozen lines of code, and they were very well concealed inside the original class.

The changed product was properly signed, so there was no reason to suspect it, and development teams trusted the owner of the code.

Only recently we’ve learned that NPM had a “logical flaw” that enabled malicious actors to pass off rogue libraries as legitimate. Basically, NPM allowed adding anyone as a maintainer of a package without notifying these users or getting their consent. 

This enabled creating malware-laced packages and assigning them to trusted, popular maintainers without their knowledge. A case of misplaced trust could mean a problematic vulnerability hidden in your code.

Another common practice to consider is developers copying and pasting code from existing libraries or StackOverFlow for use in their own code or to reupload to new libraries. Doing that raises the chance of also copying insecure and vulnerable code that is now essentially untracked. Even if the original code will get a CVE and eventually remediation, the problematic function you copied is invisible and could contaminate any codebase that would use it for years to come. 

In a recent study conducted at the University of Kansas (“What the Fork? Finding Hidden Code Clones in npm”), the researchers illustrate how using even fully vetted packages can be unsafe.

What can you do about it?

So, you cannot trust the signed products and updates of vendors. Your very own code might have already been modified or added to, due to all those external libraries and code incorporated into it. What, then, can you do to really be certain you are not installing malicious files into your system?

There are a few things you can do:

1. Request a complete SBOM from each library owner or program vendor you incorporate. An SBOM can help you make sure what all the ‘ingredients’ in the library or product are. Additionally, if you find something in the library or product that isn’t listed in the SBOM then it should be considered suspicious. You can learn more about what an SBOM is here.
2. Request a trusted attestation from the vendor or library owner that an integrity check has been made and that you are getting what you expect. You should not have to trust only the vendor’s own assurance.
   
3. When installing packages use the npm CLI flag --ignore-scripts to avoid executing scripts from 3rd party packages during the install phase.
4. Use a package-lock.json file to lock package version numbers. When you use a package-lock.json you don’t only lock the package versions you’re using, you’re also locking their dependencies as well. The risk is that you won’t be pulling in any automated package updates that might include fixes to various bugs. But, if you have put in the work to verify a certain version and do not want to include anything else without verifying it first, than locking your version numbers is the best option.

Following new regulations, most people are expected to start using SBOMs in the very near future. The more companies will ask for SBOMs and other attestations, the more organizations and maintainers will have to comply.