Worried Penetration Testing Will Derail Your Sprint Cycle?

Worried about penetration testing derailing your sprint cycles? Penetration testing can feel like a daunting task. Especially when you are unsure how long it will take, what’s expected from your vendor, and the feeling of being publically evaluated in front of your team in a subject outside your domain of expertise. Having a good understanding of timelines, considerations, and security best practices will help avoid this pain.

Does penetration testing derail sprint cycles?

It can be hard to pull resources from your development team for security when a large focus is meeting client commitments and pushing new features and updates at a consistent rate. Some development teams work with regimented sprint cycles and aren’t able to take on anything additional until they fully understand the amount of time, effort and resources required for security. Other teams may have more flexibility when it comes to security work. Lack of information available can lead to teams underestimating the efforts and rewards of penetration testing, and often leave them with condensed timelines for audits, and overall anxiety for the developers and greater team.

In order to combat this, imagine if you considered security remediations and efforts as another feature you have to build. If you are doing business with enterprise clients or companies in healthcare, fintech, security or any government or regulated industry, your security is a feature that their team expects and is often built into the contract. Most development teams should aim to dedicate 2 - 4 hours of security work for each cycle, to reduce bottlenecks of security work distracting from other planned efforts.

In order to help prepare your team and plan for your next penetration test, let’s look at penetration test timelines and considerations.

Understanding penetration testing timelines and consideration

These are the 2 most common scenarios in which you need to consider penetration test timelines:

1. Your clients are asking you to prove security maturity and a penetration test seems like the best way to do so.
2. You are beginning your security compliance (SOC 2, ISO27001, HIPAA, PCI) journey, and require a penetration test to assist with prioritizing security risk.

If you are in scenario 1, being proactive with a penetration test will help you understand your real security risks for your organization and clients’ data, as well as helping you prepare for future compliance endeavours.

If you are in scenario 2, it is important to take into consideration your audit timelines alongside your penetration testing efforts. Understanding the preparation and planning needed will help make your SOC journey smooth and efficient (potentially reducing more administrative controls).

Here is the typical breakdown of a penetration test.

Planning and pre test

In general, it is good practice to start to plan 2 months before your desired penetration test date. If you are completing your compliance journey, it is recommended to start 2.5 - 3 months before your audit start date.

This planning can include:

• Evaluating various penetration testing vendors methodology and business models
• Scoping attack surface, obtaining quotes
• Involving all necessary stakeholders in the decision making process
• Cleaning up tech debt should the scope affect price outside your budget
• Budget approval and other procurement best practices led by your organization
• Scheduling and onboarding for the penetration test

The scoping process to understand your full attack surface, should take 1 - 2 hours maximum.

It’s best to plan for 2 - 6 weeks lead time to ensure a spot on your choice pentest vendor’s calendar. Once you have a date booked for your penetration test, you will begin onboarding.

During the test

A penetration test will generally take  2 - 4 weeks if your vendor is high quality, does the majority of testing via manual efforts, and writes custom test plans for the business logic of your application.

On the first day of penetration testing with Software Secured, you will attend a short kick off meeting to provide a technical demo of the applications in scope, ensure account access has been provided and answer any questions you may have. At Software Secured, you will also get to meet the pentesters and join your slack channel. This takes no longer than 1 hour.

During the test, you will only be contacted if a critical vulnerability is found, in which case, you will be notified as soon as possible. Other than that, unless there are any blocks to access or further information needed for increased testing coverage, you won’t be contacted until the test is completed.

After the test

After you receive your penetration test report, your remediation plan is dependent on a few factors, such as your service level agreements (SLAs) with your clients, within your Vulnerability Management Policy or those recommended by your pentesters, as well as your vulnerabilities’ severity, volume and overall risk tolerance. With Software Secured’s penetration testing clients, we offer a read out report meeting to go over priorities, steps to remediation, and answer any questions around delegating and accepting risk. This helps accelerate fixes for your team and serves as an awesome security education opportunity with real code your team has written.  

You need to solve any criticals within 2 weeks maximum of getting your report, it is ideal to plan 2 - 3 sprint cycles to close all criticals and highs and document your remediation plan in your risk registry which is required for SOC 2 and other compliance frameworks.

After your team has completed remediation efforts, you can request a re-test to confirm your vulnerabilities have been fixed. From request to retest, this can take an average of 48 hours if the vulnerability is critical, or up to 1 - 2 weeks depending on the vulnerability (severity, volume etc.) and your vendor’s testing schedule.

Looking for a resource to help quantify developer time for a penetration test? Download our Quantifying Developer Time resource here.

Aligning penetration testing with your sprint cycle

Learn what to expect from your penetration testing vendor

In order to align your penetration test to your sprint cycle, it is important to know what to expect from your vendor. This can include confirming scope, planning your penetration test well in advance of your audit dates or enterprise commitments, and prepping your developer schedules with ample time for pentest set up and remediation.

Watch 5 Scoping Questions You Need to Know Before a Penetration Test

Here is a sample of our scoping questionnaire before a penetration test with Software Secured.

Knowing what information will be required from your vendor to begin the pentest will save you a lot of time and effort. Download our Sample Penetration Test Pre-Assessment Checklist to understand what information your vendor might ask for before your penetration test.

Bonus Tip:

It is easier to do pentesting before a SOC 2 audit, instead of at the end of the audit with a lot of security work and change fatigue from closing SOC 2 controls. It also becomes easier to understand risk after seeing the report and connecting dots with SOC 2 controls and client security requirements. It is also strategic to do a penetration test first as it helps prioritize most sensitive data (such as client data in applications) and proves security maturity to your clients as you continue maturing your security program.

Evaluating your sprint cycle and security relationship

Here are some questions to help you evaluate your sprint cycle and security relationship.

Where can you make changes to integrate security into sprint cycles with more ease?

Many development teams that are aiming to shift left, have begun building in monthly or quarterly 4 - 8 hours of security effort. More is required around annual or quarterly penetration testing or SOC 2 audits such as monthly or quarterly vulnerability scanning, monthly patching of VM’s and or base containers / docker files / 3rd party libraries to maintain security health.

Are there measures you can put in place to make penetration testing easier?

For example, you may be able to reduce scope with apps that are being sunset or no longer for sale, cleaning up tech debt, or internal use applications not available publicly. Doing this results in less attack surface and less pentest vulnerabilities that need remediation or a track record indicating business rationale for accepting that risk for your compliance auditor and clients.

Are you in a place where continuous pentesting makes more sense?

For fast-growing SaaS companies that want to integrate security into their development pipeline, Penetration Testing as a Service (PTaaS) might make the most sense for your team. There are various benefits when it comes to integrating penetration testing into your security program.

Quarterly comprehensive tests ensure new product features are secure before they hit production. Integrated testing allows for lower remediation costs, developer time saved, and reduces risks of vulnerabilities found in client facing assets. This could lead to stiff financial penalties, client churn and data breaches.

Conclusion

Penetration testing will not derail your sprint cycle, if it is considered a part of it. Planning and preparation will reduce the anxiety and stress of condensed timelines and help build more security champions on your team. Evaluating and improving your sprint cycle and security relationship will help push features and updates more efficiently, without compromising security. Check out 4 Ways Security Leaders Uses Penetration Testing to Elevate Their Security Programs to learn how security leaders create efficiencies in their sprint cycles and security programs with penetration testing.