Your Silence Will Not Protect You
Vulnerability Management in Practice
The American poet, essayist, feminist, and civil activist Audrey Lorde once wrote “Your silence will not protect you.” Although written in the context of social injustice it is relevant to how we as developers treat security vulnerabilities.
Like most individuals in the general public we complain and point fingers when breaches occur. But at the end of the day, it is developers who are responsible for being proactive when it comes to security as a means of protecting their applications. While tools like virus protection systems and behavior analytics can detect issues it’s always best to ensure the application doesn’t have exploitable weaknesses.
Developing with security in mind includes many tactics such as encrypting data in motion (e.g. HTTPS/TLS) as well as data at rest (e.g. file & database encryption), avoiding known exploitable features like the infamous Javascript eval() function, and ensuring that the applications include strong user authentication protocols.
However, something that’s often neglected is paying attention to security warnings. In recent months both NPM and GitHub have invested significantly in analyzing project and producing warnings when vulnerabilities are detected. Developers all too often view these as noise, rather than as an opportunity to remediate known security issues.
GitHub
By default, GitHub analyzes your project repos against known security vulnerabilities and produces a warning when a potential vulnerability is discovered.
Clicking on ‘See security alert’ will provide more detail regarding the potential issue. This includes what is at risk, the severity of the risk, when the security alert was opened, what it was opened against, and where it was discovered in your project.
In this case the vulnerability exists in the merge package, it is a high severity risk, it was identified in this project 15 days ago, and it was found via an analysis of the package-lock.json file.
This information tells us that the vulnerability isn’t in our code per se, but is in a package our project depends on. In many cases this may not be a package the project is explicitly dependent on, but may be something another package depends on.
To get more details on the package, click on ‘Dependency Graph’ to display a link to the package containing the vulnerability. From this screen clicking on the package name will take you to that packages repo.
However, what you really want to know is how to remediate the vulnerability. To get this information, click on the release number drop down next to ‘Known security vulnerability’. The ‘Known vulnerability found’ drop down tells us exactly how to fix the issue. In this case, updating the merge package from 1.2.0 to 1.2.1.
A word of caution is in order though. While it is safe to update packages your project explicitly depends on, side effects could occur when updating packages that packages depend on. An example of this is if the security remediation required a change to an API or exposed a behavior that wasn’t there in the version containing the vulnerability.
If you are interested in learning more about the specific vulnerability you can use the Common Vulnerabilities and Exposures (CVE) number to get more detail. The CVE is a list of uniquely identified, publicly known vulnerabilities.
Click on the CVE number in the drop down to display the entry for the vulnerability on the National Institute of Standards and Technology (NIST) site. This site contains a description of the vulnerability, when it was published, and links to other sites containing even more details. This information is valuable to learn not just what is vulnerable, but the details of how the vulnerability is exploitable.
NPM
Another tool that has greatly improved its stance towards security is the Node Package Manager (NPM). Following several high profile security issues NPM, Inc. has taken a leadership role in securing the package environment.
You may have noticed messages such as the one below when installing packages with NPM,
Running npm audit displays a list of the vulnerabilities, the dependency chain, and where to get more information. Keep in mind that since a package can be a dependent of multiple parents, there can be more than one entry for the same vulnerable package.
The ‘More info’ URL provides a reference to an authoritative website containing specifics about the vulnerability. Opening a browser window using this URL provides an overview of the vulnerability, its history, the versions of the package that are vulnerable, and a link to even more information.
One thing that differentiates NPM from GitHub is the npm audit fix command that is provided to actually resolve the issue. This is something GitHub can’t do automatically since it’s merely the host for the project repo.
In this case, running npm audit fix resolved the issue and subsequent application testing showed there were no ill side effects.
Conclusion
Protecting applications against sophisticated threats and bad actors requires that developers take an active role in understanding basic security protocols and remediating vulnerabilities wherever and whenever they are found.
This is especially important given the reliance on interconnected functions and services prevalent in today’s computing architecture. As a developer you can no longer afford to take a passive role towards security.
Be engaged, be active, and protect your users.
What is Chingu?
Come join us at Chingu.io to get out of “Tutorial Purgatory” by joining one of our remote Voyage project teams to build apps, refine “hard” skills, and learn new “soft” skills. We help Developers bridge the gap between what they’ve learned and the skills employers are looking for.
