We’re working with a number of clients to embed security testing earlier on in the development lifecycle to bring about more secure systems at a lower overall cost.
There are a number of modern approaches to development, each of which works well for different projects. Whilst we are able to work with whatever approach your organisation uses (or indeed help you to pioneer a transition from traditional development practices), we have focussed primarily on agile scrum development for the purposes of this article, as it is the most common development framework we see across our continuous testing projects.
Traditional Penetration Testing
Traditionally, penetration testing is conducted right at the end of the development process, when the product is ready for release, or sometimes even after release. This approach to penetration testing is often adopted in both traditional (waterfall style) development projects, and those following an agile or hybrid approach.
Traditional Waterfall Development
In a waterfall development cycle, security testing only takes place at the end of the project, immediately before release. If critical vulnerabilities are identified during a security assessment, this can derail the entire project, introducing significant delays and increasing the costs of delivery, potentially causing the project to be sent back as far as the design phase.
Traditional Penetration Testing Applied to Modern Development Frameworks
Even when a modern approach is taken to the development process, security testing is often forgotten about or ignored until significant milestones are reached, or conducted only once a year. This means that a feature could have been in production for 12 months before any security defects are identified within the code, leaving the organisation and its customers exposed.
Embedded Penetration Testing
As many of our clients move to agile or other iterative development methodologies, they are looking for innovative and efficient ways to embed security testing into the DevOps lifecycle. There are a number of advantages to an embedded approach to penetration testing as opposed to a traditional bolt-on approach.
What is Embedded Continuous Penetration Testing?
Our consultants can come in at the end of each sprint (or at the appropriate point if other development methodologies are being used, such as at feature acceptance) and conduct a penetration test of the features which have been added or changed over the course of the sprint. This has a number of advantages over the traditional approach of conducting security testing only upon completion of the project, or at infrequent intervals.
These advantages include:
- Time & Cost Savings
- Developer Education & Awareness
- Overall Security Improvements
- Easier-to-Digest Reporting
Time & Cost Savings
By testing small changes frequently throughout the development process, security defects get identified in a much shorter timeframe than the traditional approach to security, where defects may go 12 months before being tested for and identified. As issues are identified at the end of each sprint, the defects can feed directly into the next sprint for resolution. This allows developers to implement the fixes while the code is fresh in their minds, reducing the time (and cost) taken to triage, identify, and resolve each vulnerability. The fix can be implemented and ready for retesting as soon as the next penetration testing window, ensuring that the release isn’t delayed, and that the vulnerability never makes it to production.
Developer Education & Awareness
When we conduct continuous security testing for our clients, Context’s consultants usually work directly with the development teams who are actively working on the project. This allows us to gain a better understanding of how the system being developed should function, enabling conversations that deepen understanding for both the consultant and the developers. By combining our in-depth security expertise with the development team’s intricate knowledge of the system under development, we can take a collaborative approach to identifying, classifying, and proposing solutions to mitigate vulnerabilities we identify. This collaboration creates a paradigm shift by giving developers a better understanding of the issues and vulnerabilities we look for, the mind-set of an attacker, and helps to nurture a more holistic approach to development. This shifts security left, leading to a transformation that both reduces the reoccurrence of similar strains of vulnerabilities and increases code quality in current, and future projects.
Easier-to-Digest Reporting
In traditional penetration testing, the client is provided a report which details each of the vulnerabilities along with a breakdown of Context’s technical understanding of the risk each vulnerability poses. This report is great from an audit and compliance perspective, as well as for consumption by risk owners and key stakeholders, as it allows organisations to get a snapshot-in-time view of the overall risk profile of the system. However, in modern development environments, where the focus is on combatting vulnerabilities before they even make it to production, a much more developer-focussed approach to reporting can be taken. When conducting continuous security testing, our consultants usually enter identified defects directly into the customer’s issue backlog, writing the vulnerability reports in the same style as standard tickets raised for other development tasks.
This allows the defects to be consumed quickly by the project manager and the development team, and actioned immediately for remediation. Additionally, as our consultants gain a more in-depth understanding of the system under test, we are able to better advise on the business risk of identified defects, allowing for more effective contribution relating to defect triage during backlog management sessions. This reduces the time and cost associated with converting a standard compliance-focussed report into something that the development team can digest and action.
Overall Security Enhancements
When working alongside our customers in a continuous development cycle, we have identified a consistent improvement in the quality of code output as we go through more cycles together. In the early days of a project, we frequently identify the same vulnerabilities over and over. However, as we collaborate with the development team, and enable them to gain a better understanding of the ways in which security vulnerabilities are introduced into code, we see a steady decline in the frequency and severity of the defects we identify. This steady decline in vulnerabilities demonstrates how embedding security into the development process at an earlier stage has a tangible and persistent effect, improving the quality of code developed, and in turn, the security of our digital world.
So, Should we Ditch the Annual Penetration Test?
In short, no. Many organisations require annual penetration testing for audit and compliance reasons and an annual test may have a broader scope. However, by embedding continuous security testing within the development process, and acting on identified security defects quicker, the number and severity of issues identified within an annual test is usually reduced. This helps to ensure that more products are secure at the time of release, and reduces the risk of nasty surprises when an annual penetration test takes place.