Implementing automated security testing throughout the development lifecycle is critical to avoid major problems further down the line. However, when resorting to IT outsourcing, some organizations treat deliverables as separate from their normal pipeline, leading to lax security testing.
The problem becomes even more complicated for those organizations that do all their security testing once the application has been fully developed. At this late stage, identifying vulnerabilities and working backwards to discover where they originate is inefficient. Additionally, the risk of overlooking security issues is far greater because many bugs don’t cause issues in the functionality of the software.
These issues are compounded by the fact that a significant number of organizations don’t employ automated security testing in the software release lifecycle at all, instead relying on manual testing. In fact, according to the Cybersecurity Insiders 2018 Application Security Report, only 43 percent of organizations resort to automated security testing.
However, that doesn’t mean organizations aren’t aware of the issue. The Sonatype 2018 annual DevSecOps community survey revealed that 33 percent of respondents’ organizations had experienced breaches resulting from issues with web applications or open source components over the previous 12 months. This led to 73 percent of respondents stating their organizations had a greater interest in implementing and investing in security practices.
Thus, an increasing number of organizations are now implementing security testing through the development lifecycle, rather than tacking it on at the end, as an afterthought. However, adoption is still not as widespread as it should be.
Automated vs Manual Security Testing
The first step to adopting automated security testing and implementing it efficiently, is to identify the areas where it would do the most good.
Automating security testing doesn’t mean eliminating manual testing completely. The goal isn’t to throw the baby out with the bathwater. Instead, it’s important to analyze the product lifecycle and identify where automated security testing can do the most good.
By implementing automated security testing, you can then focus your manual testing and improve its value. Manual testing is still essential because it can identify errors in the process that automated testing can’t.
In automated testing, the system can only identify the vulnerabilities it has been programmed to look for. It certainly can’t identify problems in business logic, which is where manual testing comes in.
In other words, automated testing shouldn’t replace manual testing. For the best results, you should use both because they each have a vital role to play.
Security Testing Best Practices
For the best results, your goal should be to integrate security into the software development lifecycle, instead of leaving it for later, once development has been completed. This is absolutely necessary for any organization that has implemented DevOps principles in order to gain a competitive advantage.
DevOps has done much to help companies release code at a quicker rate, ensuring they remain competitive. After all, customers want upgrades and new applications to be delivered faster than ever. Spending years on developing software is no longer possible or effective.
Integrating security testing into the process results in what is being called DevSecOps, and it has become increasingly popular. This is because not only can organizations release code faster thanks to DevOps, but they also significantly reduce the number of bugs and security issues along the way.
Here are some essential best practices if you’re looking to implement security testing into your development pipeline.
Automation Is Essential
Speed is of the essence nowadays. The faster you release products and upgrades, the more competitive you will be. To reduce the likelihood of releasing vulnerabilities along with your software, you need to integrate security into the workflow. However, to keep the rhythm, you will have to automate security testing.
When you’re putting new code into production dozens of times per day, you can’t afford to rely on manual security testing. It simply won’t be able to keep up. This means automating security testing is vital, especially if you don’t want to release buggy software.
Automate Strategically
If you attempt to automatically scan all the code for your app every day, you’ll be wasting a lot of time. It’ll certainly make it far more challenging for you to maintain a good rhythm. Furthermore, it’s not necessary.
Instead, focus your tests on the changes that have been made that day. It’s a far more efficient approach.
Also, consider employing automated DAST or dynamic application security testing. Static testing checks the code for possible security issues, whereas dynamic testing searches for problems while the app is running, in real time.
Also consider automating security tests in continuous integration platforms. This will reduce the possibility of vulnerabilities being introduced early in the development cycle.
Check Code Dependencies
The higher pace of innovation and the need to meet customer demands faster has led to organizations relying more and more on open-source software. The problem is that there are risks involved, and developers rarely have time to check the code or read the documentation.
For this reason, it’s wise to automate the processes used in managing third-party and open-source processes. It’s essential to discover if using these components is causing any vulnerabilities in your app and what effects they might have on any dependencies.
Practice a Little Restraint
Static application security testing (SAST) tools are great because they scan the code as developers write it. This way, feedback is immediate on any problems that could lead to security challenges. The ability to identify challenges and fix them as they arise make these tools essential to the software development lifecycle.
However, practicing restraint is mandatory. Often, when implementing SAST tools, the security team will set the system to check for everything under the sun. With so many checks from the beginning, developers will become frustrated and annoyed.
Instead, start off small. One or two checks in the beginning is more than sufficient. You need to gain buy-in from your developers, which requires trust. When they see how the tool helps them, they will be more open to additional checks.
Implement Threat Modeling
Threat modeling exercises aren’t easy, but they are powerful. They help your security team gain a better understanding of the threats that exist to your assets, along with where those assets might be sensitive. They’ll also help you gain more insight into the controls that already exist to protect your assets and discover where those controls need to be improved.
A threat modeling exercise could help you identify problems in the design and architecture of your software that other assessments might have missed.
While you can´t automate threat modeling, it’s still invaluable because it puts your developers in the shoes of an attacker, giving them a very valuable new perspective.
Developers Need to Understand the Importance of Security
A significant issue is that many developers aren’t aware that their code is not secure simply because they aren’t trained to consider this aspect. Thus, it’s essential to train your teams to understand how important security is, and how to take a more secure approach to the code they are creating.
How Reliable Is Automated Security Testing?
If used properly, automated security testing (AST) is highly reliable. This is because AST is not meant to replace manual testing. Instead, its role is to handle those mundane, repetitive tasks that take up a lot of time. This way, your security team can focus more on areas that need human logic to identify the problems.
AST is also only as reliable as the system you are using. If you are using custom scripts, for example, you need to ensure that it is checking for the right vulnerabilities.
Implementing Automated Security Testing into IT Outsourcing Projects
The problem with IT outsourcing is that many organizations treat software development outsourcing the same as they would a third-party vendor. This isn’t the wisest approach.
At Perficient Latin America, we firmly believe that the best results are obtained when the outsourcing team is treated as an integral part of the organization. This means that you will need to implement the same security testing practices with any IT outsourcing companies you use as you do in your own organization.
In other words, you need to ensure the developers on the team are trained to code securely. They also need to have access to the same tools, and to implement the same policies you do internally, or if different, set expectations clearly.
It’s also good practice to break down larger projects into smaller deliverables where possible. By integrating these deliverables into your software development pipeline more frequently, they will be subjected to the same rigorous security testing you run internally thereby providing an additional layer of risk mitigation.
So, when working with an IT outsourcing team, you need to implement the same automated security testing you do in your own organization. Furthermore, by breaking the project down into smaller steps, you’ll be able to more easily identify and fix vulnerabilities. This is far more effective than trying to solve all the problems when the whole project is completed, which can result in a greater risk of overlooking certain issues.
—
Want to learn more? We’d be happy to explain in more detail!
