In his blog post, Application Security: Can we Achieve it?, Dennis Hurst outlines why application security is so important. Many of the problem drivers and the impacts to the organization are laid plain. Hurst also lays out a few “broad strokes” to begin approaching a resolution. In this post, I want to discuss some of the impacts of adding a code scanning tool, like HP’s Fortify or IBM’s App Scan, to an agile development teams tool kit. I won’t go into the merits or features of tools; however, I will express my opinions on some simple and effective approaches to rolling out a tool/program, as well as minimizing the impact on the development team.
Communicate on the team level:
One approach discussed by Hurst is “integrating security into the dev process, not dev into the security process.” This starts by communicating on a development team level, working directly to plan and execute within their process.
It’s an obvious thing to say that communication is paramount, but effective communication will make the roll out of any tool, program, or process more efficient and impactful. Whether you have one, ten, or even one-hundred development teams, introducing a new feedback loop will cause disturbance. The addition of a source code scanning tool to a development team introduces information that the team must now process, and sometimes it can be a significant amount of information.
Communicate with team leadership to coordinate a good time to introduce the team to the tool. I know an old fashion tool demo with some coffee and doughnuts might sound cliché, but the goal is to familiarize the team with the tool and the information they will need to consume.
Demonstrate the tool:
Whether virtual or live, this could be their first exposure to a code scanning tool. It’s important to showcase the data, otherwise known as vulnerabilities, that the teams will need to incorporate into their feedback loop. It’s also important to cover expectations of how the tool is to be used, and any major feature highlights. Have some fun with this, anything that engages the teams to want to use the tool is positive.
Review any Corporate or Information Security policies:
It can be beneficial to the teams to allow them some time to incorporate the new process, and adapt before applying Policy and Standards. In those cases that accommodation can’t be made, it may be necessary to review any and all corporate policies that the teams will need to adhere to.
Plan with the teams:
Integrating security into the dev process requires planning. Agile development teams are busy coding, testing, and releasing; because of this, it’s important to integrate with how they plan. Participate in the team planning ceremonies or meetings whenever possible. If teams are using SDLC tools to manage their life cycles, integrate with those tools. Well maintained backlogs are good places to integrate. Poorly maintained backlogs are not.
- Plan to Scan- commit to executing an initial scan
- Plan to Review- commit to reviewing the results of the scan
- Plan to Act- commit to the next course of action based on the results(next course of action should be guided by corporate policy, exposure, risk, and prioritization)
Scan early and often:
Executing a static code scan, dynamic scan, or pen test marks the beginning of the feedback loop. Scanning early and often in the development life cycle leads to better coding practices, and makes remediation of issues more efficient, which leads to predictability.
I’ve seen many teams get bogged down by the results of an initial scan, so I suggest focusing on the cadence of scan, review, and act. Acting on results can mean as little as doing nothing, introducing a single fix, or working to resolve all issues.
Teams that develop on short cycles and release regularly are successful scanning once per cycle. Teams that develop over longer cycles and release infrequently, are most successful scanning often throughout their development cycle.
- Whenever possible, automate. Automating the process of scanning brings consistency to the first step of the cadence. Automated scanning via a build pipeline is ideal, but may not always be possible. Anticipate the first cycle of Scan, Review, and Act to take more time than you might expect.
- Teams may need multiple cycles to adapt their process to incorporate the new feedback loop.
Remediate regularly:
The regular remediation of issues is really where the rubber meets the road. When teams work on fixing or remediating issues often:
- Coding habits improve
- Code base becomes less vulnerable
- Costs and effort required to maintain the code are reduced
In a perfect world, every team would see the value in this, and make it a priority. Since we don’t live in a perfect world, some teams will need more support to be intentional about allotting time and completing fixes. Integrate with the teams’ existing method or process of remediating issues or defects. If teams use defect tracking tools, explore the feasibility of adding security vulnerabilities. Wherever policy does not dictate, allow the teams to decide how they will manage remediation of issues.
Often policy dictates timelines for fixing issues. Many times, teams are overwhelmed with findings from a first scan, if time cannot be allotted to deal with all the findings, work with the teams to assist in prioritization.
Incorporate:
Incorporating application scanning into the teams’ process is ultimately up to the team. It bears repeating, that some teams may need a cycle or two to adapt their process to include the feedback loop generated by application security scanning. The goal is to integrate security into the dev process, allowing Agile teams and organizations to deliver faster with less risk.
How do we know if or when we have achieved this goal? The answer to that question is as unique as each team and organization. There are however, some general markers or milestones that can be used.
- Is the team scanning with a regular cadence that parallels the teams normal SDLC?
- Are security issues remediated just as functional issues?
- Is automation in use for scan execution?
- Are security considerations part of the teams planning process?
Reporting and Metrics:
Many good arguments are made on the topic of metrics and reporting both in the positive and the negative. I won’t debate the merits of any metric or report. Policy often does dictate reporting; where it does not, I would offer a couple of recommendations.
In the beginning, place more value on data that shows the maturation rate of incorporating security into the dev process. Markers discussed above indicate that, if the team has made application security scanning part of their normal development process. That does not mean to disregard data concerning the applications state, this must, of course, be addressed.
As the team matures, and as security becomes a part of the team’s normal process, data regarding the state of the application will naturally become the focus. I’ll leave a detailed discussion on reporting application security to another post.
Summary:
I’ll take a moment here to advocate against a couple of things. These seem so obvious and simple, yet I see it too often.
- Don’t throw a tool over the wall to a development team and expect them to utilize it in a way that maximizes your investment in the tool without support
- Don’t ask a team to conduct an initial scan right before a release, and hold hostage the release, based on the scan results
When rolling out an application security program or adding a new tool, minimizing the disruption to the development team will go a long way in making the roll out successful. Agile development teams operate differently from traditional waterfall teams, and security should support these teams, not be a hurdle they must overcome.