Component Choice
Programmers use lots of components – chunks of software written by other people. These components frequently have security issues. So make sure you choose secure components, and keep all your components are up to date.
Components, plug-ins, development frameworks: we cannot avoid them. It is components that give simple lines of code, in languages that are relatively little changed since the early days of computing, the power to create the complex and sophisticated software we rely on today.
However, components can bring with them enormous baggage: thousands of lines of code, references to other components we know nothing about, unknown quality and test status. A component from a reputable open-source library might be the creation of brilliant developers, tested by thousands of experts; or it might be a first creation by a novice programmer.
WordPress plug-ins are an enormous liability. Anyone can write one, most of them are rubbish. Anyone can get them put up on the plug-in directory, which gives them this air of authenticity, and quality that they don’t deserve, frankly. (CEO, outsourced secure web developer)
This means, unfortunately, that components are the first and simplest way for an attacker to break software.
So from an attackers point of view, you look at whatever the system is, you don't need to look at the code at all, what [components] would they have used to produce this... And you'll find code exploits! You'll find the OWASP 10 in one [component] alone! (Security consultant and Pen tester)
So as a developer, one of the first and most powerful ways to ensure the security of our software is to choose only appropriate frameworks and components. If you are helping developers to improve their security, this is one of the first things you will need to address.
So that is one of the things we end up sitting down with ... developers going 'I'm sorry, but I know this is actually going to slow you down'. And we are desperately normally trying to avoid that, I'm trying to make your lives as easy as possible. ... But [I] have to say “well, no, you can't just add components – you have to review them, you don't have to do the most detailed review in the world, but if you think it looks worrying, then don't put it in your code”. (Security consultant and Pen tester)
There are two aspects to this. We choose components that are secure in the first place; and we update components when the component developers find and fix security problems.
Finding Secure Components
Use only secure components! It sounds simple, if somewhat limiting. But how are we to know which components are secure? If the components are open-source we could review the code in detail; that would take a great deal of effort, and we might easily miss issues. What else can we do?
Fortunately, this problem affects a large and increasing number of developers, and so there are both open and commercial solutions. The usual approach is to incorporate them into the build process: the build process ‘knows’ which components are incorporated into the system, so it’s usually straightforward to add a check whether they are acceptable. The check usually involves interrogating a web-based ‘vulnerability database’. Some of these are free like Wpvulndb for WordPress; others paid like Snyk.
[Our tool chain] also queries Wpvulndb for the plug-in that you are expecting, and tells you if there have been any published vulnerabilities in it. (CEO, outsourced secure web developer)
For components not in the vulnerability database – such as components internal to your organisation – your options are two: either you review the code yourself, or you make a judgement based on the security credibility of the supplier. Components from big, security-aware companies like Microsoft, Google or Twitter, for example, are unlikely to present a risk. Components that regularly receive security updates are likely to be OK; those that do not update are likely to be a problem.
Keeping Components up to Date
There is a second problem with components. Since they tend to be widely shared, any weakness in a component will become known to attackers, and therefore it is important to keep components upgraded to the versions in which defects have been corrected.
We keep track of all the patches and everything for all our systems. (Developer, Security-oriented phone manufacturer)
This is a second function of the vulnerability database: to keep track of which versions of components contain which weaknesses. We may not need the latest version of each component; after all, for this purpose we are only interested in updates that correct security defects.
Keeping components up to date has a cost: some updates require changes to code; others may introduce defects that were not present before. Sometimes the cost of upgrading to the latest secure versions of components may be enough to need business justification – see Security Negotiation. However at least, with the help of the vulnerability databases, there can be a good cost-risk-benefit-based decision about when to do the upgrade.
Getting the right components can be by far the best investment for your software security!