With cybersecurity threats seemingly lurking around every corner, application and data security are paramount in any piece of software. New vulnerabilities are found every day, ranging in severity from relatively benign to absolutely critical. The recent exploits in Apache's Log4j library highlight just how severe, and far reaching, a vulnerability can be.
There are many tools out there that can help flag vulnerabilities in your applications as they are identified, allowing for a faster response in deploying a patch. One such tool that we use at Missing Link Technologies (MLT) is the feature-rich DevOps platform GitLab. Those familiar with GitLab may be quick to point out that a dependency scanning tool exists for Ultimate tier users. However, we recognize that the Ultimate tier isn’t for everyone and so we are taking a different approach: Continuous Integration/Continuous Delivery (CI/CD) pipelines.
With GitLab’s CI/CD pipelines, we are able to create a variety of jobs to be run given different sets of conditions. The flexibility of these rules is seemingly endless, allowing you to tailor your pipelines to your specific use case as needed. To help guide the structure of these, our team at MLT follows a few simple “Do’s and Don’ts”:
Do:
Run vulnerability scans on a regular schedule. The timing of this may differ by project, or by the state of the project, but it’s important to regularly check for new vulnerabilities even if a project is inactive. Part of our strategy at MLT is to run these scans on a nightly basis to allow us to address any new vulnerabilities the next day or immediately, in case of an urgent vulnerability like the Log4j exploit
Run vulnerability scans when packaging for deployment. This is the most important of all rules, for obvious reasons. Even if vulnerability scans are never run at any other time, ensuring your software is free of vulnerabilities prior to release is a top priority. This becomes especially important when critical vulnerabilities are found during scanning. If the CI/CD pipeline is setup correctly, the scan results will not ‘pass this stage’ and as such, vulnerable code will not compile, let alone deployed in production.
Tailor the thresholds on your vulnerability scans to suit your project. Often times, it becomes unfeasible to ensure that your entire dependency tree is free of vulnerabilities. It’s important to recognize which vulnerabilities, either individually or by level, can be safely ignored.
Capture the output of your vulnerability scans and upload them as job artifacts. This will help with reviewing the vulnerabilities should there be too many to sort through in the job’s output.
Use JSON formatted output to drive a dependency scanning report in the GitLab UI. Attaching the JSON file to the artifacts.reports.dependency_scanning directive in your job configuration will allow you to view the results in a clean and simple manner under the “Tests” tab in your pipeline. The following graphs show an example of this
Don’t:
Run vulnerability scans on every commit. These scans can, at times, be expensive. Running them on every commit serves to tie up your pipelines and runners with little to no benefit.
Use the --level flag when performing a yarn audit. Unlike npm audit, for which the --audit-level flag controls the pass/fail threshold, the --level flag in yarn audit acts only as an output filter. When running these scans, it’s important to ensure that a complete view of the vulnerabilities is available.
Article by:
Software Implementation Manager
Missing Link Technologies Ltd.