Back
Make it Easy on the Development Team
Software development teams are often at odds with application security teams, specifically penetesting teams. In this post we explore why this happens and what five steps you can take to improve participation in security testing by the development team in your organization.
Conflicting Objectives
At a macro view, the objectives of software development and application security align. Organizations need software and security to operate. But at the micro level, each team has very different objectives that don’t align.
Development teams are measured on delivering functional code on time and on budget, yet development teams regularly struggle to meet release deadlines. There are various reasons as to why, some avoidable and some not. Common reasons include scope creep, scope underestimation, unforeseen roadblocks, and bad planning.
The application security team is at least partially measured on how many vulnerabilities they find. If they don’t find vulnerabilities, that means the development team did a good job, but the security team has a hard time justifying the value they provide. Security teams scrutinize applications deeply because their reputation depends on what they can find. More often than not, they succeed in doing their jobs. The vulnerabilities they find have to be fixed.
The application security testing (AST) process further increases the deadline pressure experienced by development teams. Fixing vulnerabilities takes time and delays code pushes. The outcome is a double whammy. First, development team’s ability to deliver on time is put in jeopardy. Second, the developers feel as though their own reputations have been tarnished if their code is found to have flaws.
It’s no wonder development teams often chafe, drag their feet, or otherwise hinder the application security testing process. They submit to testing because it’s required, but they are generally not willing participants.
Evaluating Possible Solutions
Rational arguments for application security are already well understood by developers. Training and explanations do nothing to align the conflicting objectives and outcome of application security testing. Reasoning and rationale can only increase willingness so much.
Some organizations try to bake security into the software development lifecycle (SDLC). Time is allocated for application security testing between the release date and the production target. As development projects slip, security is often the first thing to be pushed out so the deadline can be met. Development teams would rather get all the features in and risk an unknown number of security flaws, hoping none exist. This reasoning leads back to the conflicting objectives.
Automation built in during the SDLC to help catch problems early can reduce the findings during a pentest. There is a diminishing return, though. More scanners will not eliminate all of the vulnerabilities found during a pentest. And this does not solve the conflicting objectives.
Five Steps to Buy in
The best security solutions are also the most convenient. Security is often viewed as a necessary evil by those burdened by the requirements. Reducing the effort needed is the best way to improve buy-in and willingness.
Application security testing orchestration (ASTO) delivers on convenience in many ways:
Step 1
Test scheduling should be as simple as possible. Ideally it should be possible to allow self-service for development teams to view, filter, and schedule security testing slots based on the availability of application security testing resources. This approach reduces the human effort needed to coordinate and schedule tests.
Software delivery dates often slip. Rescheduling pentesting at the last minute can cause a great deal of disruption to the security team. In this case, a backlog of scheduled tests can provide a buffer. For the backlog to work, scoping information for scheduled tests must be ready well ahead of time.
Step 2
Make the process of scoping security testing as seamless and convenient as possible. Your application security testing orchestration tool should track the application scope information on an ongoing basis. Annual application security tests should allow for development stakeholders to carry over prior information. Stakeholders should review and revise it prior to testing, but it’s much easier to revise than to write the entire form again.
Passing a Word document back and forth with comments and track changes gets messy and is hard to manage. Scoping questionnaires should be collaborative web interfaces where security and development can both participate. After the development team has submitted revised scoping information, the security team should review it quickly and verify it from a queue.
If any errors or discrepancies are found, communication should be easy to follow and track. Comments and markup on the scoping form are an ideal way to enable the communication flow. The web form can be mapped into a database in a standardized way and used in automated processes, which is something a Word document cannot do.
Step 3
Vulnerabilities will be found during testing. Providing full context of how to fix the vulnerabilities with high-quality remediation instructions can save the developers much time. Avoid making the developers work to figure out how to fix the problem by providing a remediation instructions library with vetted content. Sure, pentesters can write instructions, but consistency and quality will come from a standard library.
Step 4
Developers work in their own tools. Giving them a laundry list .CSV file of vulnerabilities or a static report is not going to make it easy for them. Don’t make them load the list into their tool or force them to track on a spreadsheet. Manual processes risk losing track of vulnerabilities and increasing developers’ workloads.
Integrate directly with the development SCRUM tool. Push vulnerabilities into developers’ existing workflow with the included remediation instructions to save them time and effort . Having a bidirectional sync with the SCRUM tool also makes it much easier to track remediation.
Step 5
Retesting and verifying that vulnerabilities have been fixed should be expedient and as automated as possible. Waiting to retest for weeks or months after a developer has fixed the problem will only increase the frustration the developers feel. Some scanners can automatically verify a vulnerability has been fixed, which can be triggered based on an application security testing orchestration process. Adding retest tasks to a queue for the application security team and having a service level agreement (SLA) on the task will also ensure that the security team is following up on the fix in a timely fashion.
Conclusion
While it may not be possible to entirely remove the conflict between application security and software development, it’s certainly possible to ease the inconvenience. Development teams understand the need for security. The experience is generally the problem. Improve the user experience for your developers, just like you would for any customer, and you will have a much easier time getting buy-in for the application security testing process.
