Security advisories are one of those terms that get thrown around a lot without much thought as to what they are and what role they actually serve in helping us to work more securely.
The most basic explanation here is that these are the references and databases where issues concerning the security of software projects or products are posted to, making them easily available to the public. This is an important service as users of the software can turn to these security advisories for crucial details like newly discovered issues, fixes like patches or updates, as well as more in-depth explanations of the issues to help them form better decisions.
There is a wide variety of security advisories that span the software space from those serving users of the largest enterprise software products to those for more niche communities of small projects.
In hopes of better understanding the landscape of security advisories, we have selected three that you should probably be checking in with regularly for keeping your software and organization secure. But first, here’s a short background on how a vulnerability makes its way to publication.
How Does a Vulnerability Reach the Security Advisory?
Before a vulnerability is published on a security advisory, it first needs to be discovered by a security researcher. This person might be a bug bounty hunter in the case of commercial or proprietary software or a member of an open source community. Corporate outfits like Google’s Project Zero turn up their fair share of high-quality vulnerabilities across the board, as do some others.
Once a vulnerability is discovered, good manners, custom, and security standards dictate that the owners of the project be approached with the information that they have some late nights in their near future. This team will then generally be given 90 days to come up with a fix before the researcher takes their findings public. The idea here is to give them a headstart to work on a patch before hackers can try their luck at finding victims to exploit, but also puts pressure on the owners of the code to make sure that they do not let a potentially dangerous vulnerability fester. By the end of those 90 days, information on what is vulnerable and often how to carry out the exploit is going to be published, so hopefully a fix will be available by then as well.
At this point, the information is published on the relevant advisory, available for public consumption and giving developers and users the alert that they need to kick into action and implement the necessary fixes.
So who are these advisories and how do they differ from one another? Let’s take a look at three of the most popular ones out there.
The Microsoft Security Response Center is the go-to spot for all things Microsoft. Even if you are updating regularly like you should, in line with application security best practices, the MSRC offers additional resources such as the Security Advisory and Security Bulletins.
A quick scroll through the easily searchable Security Update Guide provides access to all of the patches and info that we need in order to stay up to date with our Microsoft security needs. This includes documentation explaining the issues, what is impacted, and of course how to fix it. There are also links to important downloads as well as the CVE ID for further research.
The National Vulnerability Database
This security advisory is considered by many to be the motherload when it comes to vulnerabilities, listing CVEs from across the commercial and open source spectrums.
Operated by the US National Institute of Standards and Technology (NIST), the National Vulnerability Database (NVD) is the searchable advisory for all of the vulnerabilities that are listed in the Common Vulnerabilities and Exposures (CVE) database.
After receiving a CVE with its ID, CVE-2017-5638 for example, the vulnerability will appear in the NVD with a description of what it is, what it impacts, an analysis of its severity according to the CVSS rating, and additional links to other valuable resources if they are available.
Apache Security Advisory
As one of the cornerstones of the open source software space, the Apache Foundation has had its fair share of vulnerabilities to contend with over the years. With a strong collection of popular projects like Struts, Tomcat, and others creating an ever-widening code base, vulnerabilities are bound to be an ongoing concern.
Thankfully they offer a comprehensive security advisory of issues impacting their projects that are fixed in their recent updates. Visitors to the advisory can gain a quick understanding of which versions are vulnerable and what the risk is if the exploitation is carried out.
Contending with the Challenge of Distributed Open Source Security Advisories
On a very basic level, the difference between proprietary, commercial, and open source software comes down to the license attached to it. However, when it comes to managing security for that software component, the picture begins to change a bit.
Security advisories for commercial software like we saw with Microsoft are centralized in a single location, making it easy for your team to keep up with new vulnerabilities and updates. However open source software advisories are highly distributed, much like the community itself. Research has shown that 97% of open source vulnerabilities have a fix available, but finding them is not always so simple.
For organizations that are developing software, this can create a challenge when it comes to keeping up on the latest developments since it means tracking multiple resources, possibly missing out on ones that could impact your product. Defending against these open source vulnerabilities is a relatively straightforward task since the fix is developed for you. However, if you do not know what’s vulnerable or which versions still have vulnerabilities in them, then it becomes significantly harder to do right. Thankfully, one of the best defenses is also one of the easiest to implement.
Security Advisories Always Stay Up to Date — Do You?
While some developers and IT pros will always have backward compatibility concerns about how an update may impact their existing software, this general rule of staying up to date should still be followed. In most cases, any issues with compatibility are addressed in the documentation, so do not let those worries stop you from being more secure.
Security teams and communities do their best to fix the vulnerabilities in their software when it is brought to their attention, and post security advisories as soon as they can. Then, it is up to us to stay updated on the security advisories and take that final step to actually implement their patches and updates.