Duis vehicula hendrerit finibus. In hac habitasse platea dictumst. Quisque aliquet, lacus eget feugiat viverra, diam dui dapibus mauris, at vehicula diam sem vitae nibh.
Most applications make use of large amounts of third-party components. These components provide everything from logging, templating, database access, and more.
This makes developing software much easier, saving a lot of time, however, these components are also made by people and some will inevitably contain vulnerabilities. This means you might be unknowingly exposed to vulnerabilities that could be exploited.
Keeping components up to date
As a general rule of thumb, it's strongly recommended to keep frameworks, libraries, and other components up to date on a regular basis. This can be done in a number of ways:
Mitigating the risk of technical debt
One rather insidious problem with upgrading libraries is that they can have code-breaking changes. While these are often documented, there can also be undocumented changes that may not appear until your code is running in production.
If your application is running many versions behind the most current one, there may be a significant amount of work needed to upgrade to the latest version. In the case where a time-sensitive vulnerability is disclosed, it's critical that you’re relatively up-to-date with third-party components to avoid a situation where the upgrade will take days to do.
It’s also not recommended to blindly upgrade packages without at least reading release notes as they may contain important information about changes that are not obvious but could change the way your application functions.
Could updating make you more insecure?
While it’s not common, there have been instances where a vulnerability may:
These cases may lead one to believe that updating packages on a regular basis isn’t really desirable. Of course, this thinking should be avoided where possible as it leads to the build-up of technical debt.
Given the relative rarity that this scenario represents, the benefits of frequently updating packages far outweigh the possibility of a newly introduced vulnerability, which should be easily mitigated anyway if you’re staying up to date on a regular basis.
It also makes the assumption that vendors don’t silently fix vulnerabilities without any disclosure, which is unfortunately still very common.
Notable examples
A few notable examples you will likely have heard of in recent times are listed below. You can see how and why it’s important to check your libraries and ensure you’re staying up to date.
We secure software through developer-driven security at the start of the software development lifecycle.
Visit Secure Code Warrior
