Boost Your Angular App Security By Continuously Updating NPM Packages
Use the ‘yarn audit' command in your CI pipeline and block the integration if there are security risks
You might have heard about the audit command in yarn. It essentially reports the NPM packages and their dependencies in your angular application that have a known security risk.
Now it would be nice if we take care and update those packages, so our application would not be exposed, as usually security issues are patched in a newer version of the package. Most of the attacks that are happening are not some Hollywood hackers that hack the system. Usually there is a ready made script (by one Hollywood hacker), used by thousands of others (who might not even know what they are doing) that exposes the security vulnerabilities of an application dependencies.
One way to prevent this from happening to your app is if you call the yarn audit command in the CI pipeline, and block any integrations that would introduce security vulnerabilities in the application. I’m going to show you how we do that using Azure DevOps, but you can obviously call this script and command in any CI solution.
Integrating yarn audit in a CI pipeline is not straightforward, as it almost always returns a non-zero exit code, which means it will always fail the step. Even using the --level argument won’t help, as it does not change the exit code.
This is the reason I wrote a script that will receive the minimum level you’d like to consider as vulnerable as an argument. Then, it will return a non-zero exit code only if there are vulnerabilities found of that level or higher. Otherwise, it will return zero exit code which will not break your pipeline.
We use the fact that the exit code is a mask, so even if you have info, low, moderate and high level issues, the exit code will not be bigger than the critical level exit code. Same goes for the other levels.
Now that you have the script, you can just create a pipeline which will install Yarn and Node on the agent, and will finally call this script, as shown below.
As you can see, we only care about critical level issues since we introduced this script a bit late in the project. The plan is to gradually lower the level, first to high and then to moderate. And this is one strategy you can utilize for your ongoing projects.
Another thing you can do is set up a weekly build, get a report out of this, and have a weekly task for your team to update packages, without failing any integrations.
Keep in mind that updating NPM packages might introduce runtime issues, so every time a package is updated, you need to run UI/End-to-end/Manual tests.
Conclusion
As you can see, with a very minimal effort you can make your angular app more secure, in addition to what angular already offers out of the box. The more important part here is that you are adding a policy that all developers in your team have to respect.