Size may not matter…but in DevSecOps, frequency certainly does!
With applications driving the global economy, developers are under pressure to deliver software and more features at an unprecedented scale and speed.
While no developer wants to create insecure products, most software products are pushed into production with vulnerabilities which stay unremediated causing a spiraling technical and security debt and significant risk for the organization.
Application Security scanning frequency really is the key, with development teams that scan for security issues early and often substantially reducing their security debt.
But what is Security Debt and how early and how often should you be scanning?
What is Security Debt?
Security debt is the continuing accumulation of security vulnerabilities in your software that compound to make it harder (read: impossible) to catch up with remediation to secure your applications and data from attacks.
Unlike technical debt, which may get in the way of releasing new features for the needs of the business, the growing pile of security vulnerabilities puts your organization at an increased risk of cyber attack. Indeed, in many cases, Medium to High severity vulnerabilities are being deferred, including issues like XSS, SQLi and others in the OWASP Top 10. According to Forrester, the average time to resolve a high vulnerability in production is 4 months. This means that you could be placing your entire business at risk for 4 months. Unfathomable, right? Yet it happens every day!!!
How is Security Debt caused?
Security debt is caused when security testing is not baked across the software development life cycle (SDLC), accumulating when development releases software without testing for or fixing vulnerabilities.
With most organizations carrying out periodic (monthly, quarterly, annually?) automated, or manual security testing, they make the decision to release now and fix vulnerabilities later. This results in an increased risk of exposure until the issues are remediated. The main issue is that ‘later’ keeps on getting pushed back and in many cases, ‘later’ becomes ‘never’, making security debt even worse!
When and how often should you be scanning?
Your Security Debt should be treated just like your Credit Card debt – if you keep spending and don’t pay off your monthly balance, eventually it will lead to bankruptcy.
With the sheer volume of iterations to applications and APIs on a daily basis, security testing needs to mirror this cadence, to prevent a security breach and potential bankruptcy too!
Heavy, periodic scanning and quick remediation over a defined limited period to meet a release deadline, forces you to defer issues and add to your security debt.
DevOps and DevSecOps focus on enabling organizations to detect and fix security vulnerabilities as early and as often as possible in the software development life cycle (SDLC).
This mindset, where everyone is responsible for security, has broken down the barriers between developers, QA and security, facilitated by security champions who know what good looks like in terms of security.
With the increased velocity of development, comes an accelerated introduction of vulnerabilities. Security testing and remediation needs to become a habitual process and part of your accelerated pipelines. Automation of daily security testing is critical to establishing a cadence of secure software
The advantages of daily scanning are clear to see:
| Periodic Scanning | Daily Scanning |
| Typically carried out manually | Integrated across the CICD with automation |
| Reactive – Security handed off by developers. ‘Tick-box’, compliance based scanning by siloed teams | Proactive – Culture of security where Dev, QA and Sec work together, enhancing DevOps / DevSecOps |
| Carried out in bursts – Monthly, quarterly, annually | Frequent, regular testing – On every build / commit or master merge |
| Finds large numbers of vulnerabilities very late, often in production | Finds vulnerabilities early to be fixed at ‘source’ |
| Too many accumulated issues are hard to prioritise | Reduced, bite size load makes prioritisation of vulnerability fixes easier |
| Increased deferral of remediation | Reduced deferral of remediation |
| Slow fix rate | 10 x faster fix rate than periodic |
| Risky security posture | Secure by design approach reduces cyber risk |
| Drain on resources and expensive to remediate issues. Heavy reliance on costly manual Penetration Testing | Cheapest and most efficient time to remediate issues. Reduces reliance on and cost of manual Penetration Testing |
| 5 x increase in security debt | Reduces security debt |
With regular testing on every build / commit, or at least daily, everyone can be focused on making better security decisions as part of a unified DevSecOps strategy to deliver software with speed, efficiency and security.
Relying on manual testing simply cannot keep up with accelerated development timelines. The success of this strategy relies on development teams having easy to use, accurate and seamlessly integrated automated testing technology.
Traditional legacy Dynamic Application Security Testing (DAST) tools are not built for this regular cadence of security testing that demands speed.
Bright’s innovative Bright technology, with no false positives, has been built with a developer first approach, to enable you to effectively integrate security scanning on every build / commit, to enhance DevSecOps and reduce your security debt. Contact us to learn more and request a demo.
