The EQUIFAX USA event of 2017 put into the spotlight an underconsidered aspect of software security: It’s not just our code that we need to secure. The facts of the case are widely known, but, its cause? Not so much. Little is said about the fact that this leak would not have taken place if the developers of the EQUIFAX application had upgraded their Apache Struts web framework to a more secure version.
We developers are not creating applications based only on our code. We rely on servers, programming languages, frameworks, libraries (wheels, gems, JARs…) and we need to secure all that, even that code we copy-paste from Stack Overflow.
When we create applications, we are not just writing code, we are building a house with Lego blocks, and our code is just a part of that house. In fact, our code is on the top of that house. All that other stuff we depend on, is underneath, it’s our software’s foundations, and if it is not secured, our house will fall apart, just like EQUIFAX’s did.
One notable thing to mention in this issue is the fact that this kind of vulnerability is listed in OWASP Top 10 2017.
The good news is that some developers have begun to take notice on the issue. There are projects available that aim to help developers to take care of dependency security even before their code reaches the CI/CD (Continuous Integration/Continuous Delivery) server.
If you’ve been involved in software development in recent years, then you should be aware of the term “Penetration Testing”.
Penetration testing (or pentest) is as popular as ever. I continue to find organizations that spend a lot of money on pentest as their primary means of security, testing periodically while they are in production, yet they are still hacked constantly.
New digital technologies and modern computer platforms allow organizations to rapidly deliver new products and services, create agile business models and revenue streams and enhance operational efficiency.
However, deploying changes faster is a double-edged sword. Consider for a moment what happens when changes contain bugs – or security issues? If there are no systems in place to guard against flawed changes being released, we risk bringing our systems down much faster too.
In this challenging software environment, businesses require a new approach: annual audits are no longer enough. In this article, we explain how you can merge manual penetration testing with automated security testing to improve your security.
New techniques for modern applications
Combining manual penetration testing and automated security testing results in a comprehensive and effective approach to safety. Although they are different, they are not mutually exclusive.
In-depth manual pentests weed out complex attack vectors. However, the amount of code pushed live every day poses a challenge as it is increasingly difficult for security teams to keep track of the latest threats. With the help of automated tools, problems can be discovered before the new code goes into production.
What are the benefits of combining annual penetration testing and automated security testing?
By using automated tools, developers can identify and solve security problems throughout the development cycle. So, while your development team solves the security problems before implementing production updates, the pentesters will concentrate on complex vectors, optimising time and cost.
How can you automate your security testing?
If you have an expert on your team or some free time in your sprint, you can integrate on-premise and open-source tools such as Nessus,