It is no secret that early security testing is beneficial. However, do you know how advantageous it is and what are the potential consequences of the lack of early testing? Here are 5 top benefits of early security testing along with the risks of late testing.
Benefit 1: Simplifying Fixes
One of the biggest challenges that developers face is working with code created by other developers. If they are tasked with fixing or amending code written by someone else, they must first understand that code. Despite the fact that modern development teams have tons of mechanisms and standards in place to make it easier, it is still a difficult task.
That is why most developers are much happier to get tasks to develop new functionality or extend existing code than work on bug reports. The situation is even worse with issues related to cybersecurity (including web security), where understanding someone else’s error might require a lot of research.
Early security testing means that the code is never accepted into the repository unless it is safe. It means that the developer needs to fix security issues before they complete their task. This, in turn, lowers the chance of later security bug reports and fixes being assigned to other developers.
For example, if the developer is working in a DevSecOps environment, they usually create a private branch in a code repository (e.g. in Git) and then run a CI/CD job (e.g. in Jenkins) to build that private branch. If code compiles correctly, the CI/CD job runs a series of QA tests: unit tests, functional tests, integration tests, and more. These tests either include or are followed by security testing using a DAST and/or IAST/SAST tool. If these tools deem the software to be insecure, the build fails. The developer has to eliminate the issues and try again.
With early testing, the developer would be unable to complete their task unless the application is deemed secure using an automated security testing tool. The detailed benefits are:
- Saving time: Developers rarely waste time trying to understand security issues introduced by others. They only have to worry about their own security-related bugs.
- Ticket reduction: There are much fewer tickets created for security-related issues. Therefore, project managers spend less time on issue management.
Benefit 2: Building Developer Responsibility
Many developers shun security. As a result, they often make basic mistakes. For example, they accept untrusted input and use it directly as part of the output.
Since the quality of code written by one developer is usually verified through peer code review and almost never evaluated by the security team, the effect persists. The reviewer might pay as little attention to security as the original author.
If the CI/CD pipelines don’t include security scanning, such insecure code goes into the repository. Your scanner discovers vulnerabilities in staging and creates new issues in your issue tracker. However, your managers need to assign these issues to developers. They have no way to know who was responsible for introducing the vulnerability and therefore cannot assign such issues to the original culprit.
As a result, a security vulnerability introduced by one developer is most likely to be fixed by another developer. The original developers are not deemed responsible. What’s worse, they might never even find out that they introduced the vulnerability!
If you run security tests at the earliest possible stage and configure your software in an appropriate fashion, a developer cannot submit code that contains vulnerabilities. This forces the developer to take the responsibility for the security of their own code. If the developer writes code badly, they will have to keep going back to it and correcting it until the scanner says that the application is secure.
With early security testing, developers realize that it is in their best interest to write secure code. They realize that if they shun security, they will be forced to spend much more time correcting their own errors. And since the security testing is done automatically, they will have nobody to blame for pointing out their mistakes.
The detailed benefits are:
- Developers realizing their responsibility: Unless developers take responsibility for security vulnerabilities, they cannot complete tasks that are assigned to them (builds fail).
- Developers realizing the importance of security: Developers stop treating security as unimportant because they realize that they have to be responsible for it.
Benefit 3: Educating Developers on Security
Renowned universities often teach their students complex development skills such as the ability to formally prove the correctness of their algorithms using invariants. However, the same universities often skip basic training on secure coding. Lessons often do not focus at all (or not enough) on the importance of distrusting user input. Therefore, it’s no wonder that most developers simply do not know how to write secure code.
In a professional environment, if a security professional tells a developer that their code is insecure, this may cause several problems. An inexperienced developer may feel anxious about their position. An experienced developer may become defensive because they feel that they have enough experience to know what they are doing. Both may end up disliking the security professional who pointed out the error.
Automated testing early in the development process eliminates potential conflicts between developers and security teams because the vulnerability is reported by a machine, not by a person. Also, if testing is done earlier, nobody except the developer knows about the vulnerability. Therefore, the developer does not need to feel anxious about being judged.
At the same time, a good security tool will not just report a security issue but will also provide information about the root cause of the security error and guides how to fix it. As such, the developer will learn for the future how to avoid creating such errors in the first place.
Automated, early security testing makes developers more at ease and helps them learn how to write secure code.
The detailed benefits are:
- Improvement of relationships: Developers learn about their mistakes from automated tools, not security professionals, and therefore there are no personal conflicts or dislikes on this basis.
- Elimination of anxiety: Developers don’t have to worry about the safety of their position in the company if their security-related skills are not yet up to speed.
- Improvement of programming skills: Developers learn by practicing (solving their own vulnerabilities) and by reading helpful additional information (provided by the tool) and as a result, they improve their secure code writing skills.
Benefit 4: Saving Even More Time
Let’s assume the following case scenario.
Your developer accidentally introduces a serious vulnerability into a new function of your application. This vulnerability goes unnoticed by the code reviewer and there’s no automatic testing in the early stages of the SDLC. This function is very important to your customers and it’s included in the upcoming, critical release.
As many businesses do, you perform your security testing only before major releases, during staging. In such a case, your testing tool will inform you about the security vulnerability just before the critical release (several weeks after the vulnerability has actually been introduced into the code).
To eliminate the vulnerability, you have to delay your release. The code has to go back to the developers, then go through subsequent QA testing phases, and finally, you put the application in staging from scratch. Due to the lack of security testing earlier on, you find that the vulnerability has not been eliminated (the developer used an ineffective workaround). You go back to the drawing board again and the critical release is now seriously delayed.
The cost of such a discovery at such a late stage may be enormous. Perhaps your customer is depending on the timely release and this has a significant impact on your business. All because of an error that was not spotted early enough.
With early testing, a situation like the one described above would be unlikely to happen. Most vulnerabilities would be caught way before the first version of the application is ready for release. Some less critical vulnerabilities may be discovered in staging (due to the ability to test the entire application on a real web server) but they would be unlikely to require a release pull-back. You can even configure your early testing to pass if the discovered vulnerabilities are automatically deemed low-risk.
Delays caused by the lack of early testing have a tendency to build up quickly. By eliminating vulnerabilities as soon as they appear, you save a lot of time. This time saving may have a critical impact on your business. But it’s not just time-saving that is important, it’s the predictability. Otherwise, potential unexpected delays may happen just before releases, making your release schedule completely unpredictable.
The detailed benefits are:
- Releasing on-time: If any part of major testing, such as security testing, is done at the last stage before the release, issues found then may delay the release. With early testing, this does not happen.
- Improved predictability: If you don’t know about critical security errors until the last moment before release, there is no way for you to predict the delays caused by such a discovery.
Benefit 5: Avoiding Premeditated Exposure
If you’re faced with a situation like the one described above, where a vulnerability that is discovered too late causes a major delay for a critical release, you may be forced to go ahead with the release despite the vulnerability. Many businesses face such a reality quite often if they don’t implement early security testing.
It’s obvious that exposing software with a serious vulnerability to the public may come with a very high price tag. Taking a chance that the vulnerability won’t get discovered by malicious hackers before the next release is like playing Russian roulette. In most cases, businesses choose to temporarily protect their software using web application firewalls (WAFs). However, that is not always possible (if, for example, the software is delivered to a third party and not hosted by the business) and WAF protection is not foolproof.
Early testing completely eliminates the risk of intentionally releasing vulnerable software. While staging-level tests and additional manual penetration tests may expose certain vulnerabilities that were missed during automated scans, the risk that these vulnerabilities are serious is very low.
Avoiding the need to intentionally release vulnerable software is a huge benefit in itself. However, avoiding such situations comes with many added detailed benefits such as:
- Predictable releases: The team does not have to worry about problems being discovered at the last minute and requiring critical decisions.
- Improved trust: Stakeholders such as upper management or external clients retain trust in the quality of the software and the process.
- No risks to compliance: If your business must choose between delaying critical functionality changes or intentionally exposing a vulnerability, this may affect your compliance.
Early Testing with Acunetix
Acunetix is being actively used for early testing by many customers. Basic integrations are very easy and can be performed in just a few minutes, either by your DevOps or with the help of our support. Here are some examples:
- How to integrate Acunetix with Jenkins
- How to integrate Acunetix with Jira
- How to integrate Acunetix with GitLab issue tracking
- How to integrate Acunetix with GitLab CI/CD
- How to integrate Acunetix with GitHub issue tracking
- How to integrate Acunetix with Azure DevOps issue tracking
- How to integrate Acunetix with Azure DevOps CI/CD
In addition, if you need more complex integration (such as for example, one of our major customers), you can always use the Acunetix REST API to build custom integrations. Here are some examples of how to use the Acunetix REST API in practice:
- Example Bash Script for the Acunetix REST API
- Example PowerShell Script for the Acunetix REST API
- Example Python Script for the Acunetix REST API
- An advanced example of using the Acunetix REST API with Python
DOWNLOAD FEATURED DOCUMENT
DevSecOps with Acunetix – Why Do You Need It?
Download this presentation to find out how you can solve several common problems by including Acunetix in your DevSecOps processes.
DOWNLOAD FEATURED DOCUMENT
DevSecOps with Acunetix – Why Do You Need It?
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Tomasz Andrzej Nidecki. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/pfmPDI6kgik/