A predictable and efficient Software Development Lifecycle (SDLC) is crucial for delivering modern web applications on schedule, in scope, and within budget.
As attack surfaces expand and malicious activity continues to rise in 2022, legacy AppSec tools and strategies are failing enterprises, leading to a security crisis.
All of this is made worse at a time of heightened cybersecurity threats from nation states and an acute skill shortage within the security industry to be able to manage and deal with thse threats.
Security must be embedded throughout any application’s SDLC to reduce the risk of breaches at a later stage through vulnerabilities. If businesses were focusing on integrating security into development workflows, we’d probably see declining rates of cybersecurity incidents. Instead, each year they continue to grow.
“96% of web applications have at least one vulnerability”
Application developers already have a full schedule of work, adding features, application performance, updating code, and documenting software. This means security doesn’t always rank at the top of the list of business-critical priorities for their role.
Building security into the application lifecycle via the SDLC is not an easy task, as security is not a feature that users request or can be sold on. It is assumed to be there, a “hygiene factor.” It can also be very hard to deliver, often requiring developers to learn a new range of skills.
We know that many applications do have issues. In fact, 89% of developers knowingly release vulnerable code at least some of the time, while quality assurance teams typically check functionality, not security.
Depending on the size of your team, the focus has traditionally been to do a deep security dive only occasionally, when big issues or releases come up – pen testing is expensive, so it is done infrequently, maybe only annually.
So, as a business grows, it may decide to bring pentest tools in-house, requiring highly skilled staff who can work with specialised tooling and interpret the complex issues.
With the current skills shortage that the industry is experiencing, a growing business will be looking for a solution that can be managed by anybody within the IT team – not just the specialists.
Typically, the security team are focusing on infrastructure and do not see it as their responsibility to allocate time and effort to managing vulnerabilities in the code. So, they want to delegate responsibility for the app security back to the developers or shift left.
Evolution of the SDLC (software development life cycle)
In the pre-web era, the software development process usually had a clear start and finish, progressing in a linear fashion and handing off deliverables from one isolated phase to the next, often on a schedule that could span years.
This process made it very difficult and costly to go back and make any changes to address, for example, a security vulnerability.
Subsequent development methodologies were created to allow software to be delivered and adapted more frequently in smaller cycles and given to the customer incrementally instead of holding everything back until the full project scope was ready.
This made it possible to gradually add functionality and adapt the product as necessary.
The iterative and incremental approach for an SDLC has culminated in modern agile methodologies with continuous integration and continuous deployment (CI/CD).
Security in different SDLC models
As development methods evolved and were accelerated by building ever more automation into build and test pipelines, the dedicated security testing phase became a major bottleneck.
At the same time, the importance of application security grew. When businesses started moving to the cloud and web applications became the foundation of entire business models, it suddenly became necessary to keep them secure while also shortening release cycles.
This was when agile development with DevOps really took off, allowing relatively small software development teams to deliver and deploy large and complex applications thanks to extensive automation.
While this unlocked massive business opportunities, it also expanded the potential attack surface and left conventional application security testing even further behind.
Even today, application security still often takes a back seat to release schedules, with as many as 70% of development organisations skipping at least some security steps when deadlines loom.
How to protect assets and respond to cyber threats
The resources that manage security in an organisation span, multiple teams, use various tools and have different objectives and targets.
Organisations are looking to improve their security by automating processes to minimise costs and – crucially at a time of an acute shortage of skilled labour – apply tools that are easy to use and interpret.
The team responsible for vulnerability scanning typically focuses on a specific scanning toolset, while the people responsible for patching or remediation typically work from ticketing systems. This mismatch often makes matters worse.
To state the obvious, the act of getting a list of vulnerabilities does not improve security. It is only when actions are taken to remediate (or mitigate) those vulnerabilities that security overall will improve.
Recommended reading: Check our Maturity Assessment Model.
Automating the process
It is probably worth stating the “vision” of where most organisations want to be.
In the real world, we want to monitor the complete process flow and ensure progress is being made, but other than that, everything else is automated. No emails, no Excel files, no being chased on the phone – it should just flow in one continuous process.
For the flow to work, the process has to be clearly defined and agreed upon.
If you want to automate and standardise things, you need to have a clearly defined set of rules on how things happen.
The process should define how you measure the severity of a security issue, how it gets fixed and in what time frame and what interactions take place between the various teams.
When you have a fully agreed-upon and adopted process, you are able to develop automation.
Recommended reading: Vulnerability Management Programme and automating processes blog.
A security-first culture among developers
There are, of course, some drawbacks to just expecting developers to take on the mantle of security. Notably, there may be a need for retraining at a time when they are already at full capacity.
Inefficient communication between developers and the security team can also slow down the overall software pace of software development – never a good thing.
From a developer’s perspective, a major challenge is the constantly changing threat landscape. Developers are not security experts, and the feedback loop between dev and security teams does not always function as it should.
For instance, you could have a breach that was not directly caused by an application problem but was nonetheless made worse by a vulnerability in the code – a vulnerability that was not caught until after the coding process was complete.
Developers need to be motivated to write secure code in the first place, as this reduces the number of defects that they have to go back and fix retrospectively after an application has been released.
Developers should also be empowered with the right tools that make it as easy as possible for them to write secure code and identify security risks that may linger in their environments.
Companies will often have a security mindset that focuses on maintaining a secure production environment, which is more manageable for security teams but not a viable approach for helping developers to improve application security.
So, business leaders should make sure to invest in security tools for developers, notably including suitably modern tools for dynamic application security testing (DAST).
These types of solutions can help developers detect and remediate more security issues during the software development process without having to wait until the staging and deployment phases to find flaws.
Ask for a free Invicti consultation.
DAST – Dynamic Application Security Testing
Automated DAST tools, also called vulnerability scanners, work by accessing a web application and simulating the interactions of user browsers to probe the application for potential security issues.
The types of issues that DAST can find are categorised reasonably well in the OWASP Top 10 and include common weaknesses like cross-site scripting (XSS) and SQL injection. A good scanning tool can also find more subtle errors like insecure cookie handling, out-of-date libraries in use, misconfigurations, and so on.
A few things to keep in mind about DAST:
- Vulnerability scanners are only used for web applications.
- DAST is programming language-agnostic, as the scanner examines application behaviour, not code.
- A scanner can only test areas of the application that it can access.
- When an issue is identified, it is up to the developer to work out what happened and track down the specific line of code.
- You can also test an application for which you do not have the source code.
Recommended reading: What’s the difference between DAST vs SAST vs IAST?
Invicti products
For most organisations, the biggest pain point is not finding security vulnerabilities or even fixing them – it is a chronic shortage of security skills.
To address this, Invicti products bring a unique approach that enables organisations to effectively manage their entire web application portfolio by maximising automation, coverage, and accuracy.
Invicti – Fully integrated into SDLC and DevSecOps workflows
Invicti integrates with your SDLC and development management systems. It can even create an issue in an external tracker, assign it to a specific developer, notify that developer, and automatically retest the fix once the issue is marked as resolved.
Closing the Appsec Gap – Invicti’s Continuous Application Security Approach and SDLC
Next steps
Invicti is a web vulnerability scanning solution that makes it easy for security teams, developers, and QA teams alike to pinpoint critical security issues and assess their potential consequences by automatically crawling and scanning all types of legacy and modern web applications.
With the right solution, you don’t have to compromise. You can build a complete application security programme that covers every corner of every application.
Where to start?
S4 Applications can help your business review its ability to protect assets and respond to cyber threats.
In simple terms, where does your security strategy stand? What are your biggest risks? What are your regulatory and compliance obligations? Where should you focus your efforts? What are your aspirations?
S4 Applications can help make vulnerability and threat management a strategic priority in your business. Book a consultation and let us know what challenges you want to address.
Book a demo for Invicti / make contact for a consultation.
We have also a blog that would be good to read together with this blog, on our 8 Best Practice Steps For Effective Vulnerability lifecycle Management.