This is the third blog (first one here, second one here) from a meeting of the North-East England chapter of (ISC)2, where security experts from the region used the world café conversational format to discuss a number of topics. I lead a table discussing secure software development and the topic of software requiring maintenance over time came up as a key issue.

When software is released it can be pen tested and deemed largely secure, but those test results are point-in-time assessments of the application’s security, they are only valid for the time at which the test was done. The very next day new attacks or weaknesses could be found that render your software at risk. Leaving that software alone for weeks, months, or even years without some sort of maintenance practically guarantees that there will be vulnerabilities available to attackers who look closely enough.

Weaknesses come in many forms, for instance code libraries that you include in your software may be tested and found to be vulnerable to attack. Good libraries will be maintained and when vulnerabilities are found the problems will be corrected, but unless you know all of this has taken place then you won’t go off to get the latest version of the library and add it to your software. An attacker can see which versions of a library you use and if you’re using an old version with known vulnerabilities then they could use that as an attack vector.

Fact: Without maintenance, software it will become less secure over time.

There are many different options to help you with your problems, such as:

• Dependency checking tools like OWASP Dependency Check, Snyk, and Retire.js to name but a few, which check common libraries for vulnerable versions
• Static Application Security Testing (SAST) using tools like Fortify, SonarQube and Roslyn Security Guard to scan source code for common anti-patterns and issues
• Dynamic Application Security Testing (DAST) using something like OWASP ZAP, which works with running web applications to help to spot common vulnerabilities

A lot of the above options can then be automated to allow scans to run at the push of a button, or could be set to run on a schedule to run scans every week or month, notifying you if there are issues. It would be even better if you set up this automaton as you start developing your software, then it should be simple to continue maintenance into the future.

Respect the people who use your software!

Running these scans is relatively straight forward and if you have respect for the people paying good money for your software (or even if you give it away free) then you owe it to them to consider security!