Vulnerability Management

How SaaS companies can meet the reqs for SOC2 and ISO 27001

For executives, founders, and business leaders, having a vulnerability management program is one of the often misunderstood requirements of audited frameworks like SOC2, ISO 270001, and NIST.

In this board brief, I’ll explain in the simplest terms for a non-technical audience what it is, how it’s measured during an audit, and what you can do right now to comply with this requirement.

There are many things that sound like they could be related to the words  “vulnerability management”, but the ones the frameworks focus on are very specific. 

Vuln Management is part of the secure software development lifecycle, which includes all the various things software developers have to do on an ongoing basis to ensure the applications they work on are secure from the most common types of threats. 

All software is built using libraries and packages. These are basically other people's code that make your software work, and most are open source. They can be tightly intertwined with your code or in the underlying OS that your application uses. 

As hackers and researchers identify security issues in packages, the maintainers, the people who write the code for them, update their libraries to fix the vulnerabilities that have been identified.

But not every update to a package fixes a vulnerability, most add features and can change how the package works. Updating to a new package that isn’t backward compatible could break something in your application. That’s why this can get very frustrating and time-consuming. 

But this is one of the most important things developers can do to secure their applications. This is literally how attacks on software happen: a well-established vulnerability is exploited to compromise your software.

Ok so, how do you pass your audit? 

During an audit, this is measured by examining the length of time a package that has been identified as vulnerable and then fixed or updated. 

Vulnerable packages are scored by how sensitive they are and auditors will look to make sure highly sensitive critical packages are updated within 30 days, or sooner for example. Less sensitive packages could be 60 or even 90-day timelines, or until they become severely critical. 

How do you actually get this done?

Detecting and triaging the vulnerabilities is thankfully very easy. 

Github’s Dependabot and Snyk’s free plan both cover everything you need to detect vulnerable packages. Did I mention they’re both free? 

Tools like those will continuously monitor and generate the list of vuln packages. They will even rank them in terms of importance. 

Now, this is the hard part. Developers will have to test to ensure that upgrading the packages doesn’t break their application. This is real work; it’s not just changing the version number of a package in a requirements file. Upgrading certain packages might require upgrading others or changing things in how your application uses that package. 

So how do you do this? You need to make vuln management a part of your normal software development process. Upgrading packages regularly. 

Some of the worst offenders I’ve seen are companies that leverage outsourced developers or development companies who write code and then forget about it. Upgrading packages from last quarter's version is significantly easier than upgrading a package from 3 years ago.

👋 What did you think of this post? I’d love to hear your feedback!