An industry consortium dedicated to assuring the security of software has issued guidelines to lower the risk that vulnerabilities that could be exploited by attackers will wind up in finished code.
In particular, the Software Assurance Forum for Excellence in Code (SAFECode) is addressing how to prevent vulnerabilities that may worm their way in during the Agile software development process.
MORE: SAP designs facility for ‘agile’ cloud application development
RELATED: ‘Rugged Manifesto’ promotes secure coding
Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com
Agile is a framework for incremental software development by teams that work together in stages called sprints to develop the first iteration of code then revisit it regularly to refine the product based on new requirements and input from users.
SAFECode’s new paper, “Practical Security Stories and Security Tasks for Agile Development Environments,” presents Agile teams with a list of specific goals they may be trying to achieve at the outset and tasks necessary to achieve each one.
These tasks are refined at the end of each sprint in preparation for the next one, but they set Agile teams on a path that will lead to a safer end product, says Edward Bonver, a principal senior software engineer at Symantec who participates in SAFECode. The organization is made up of some major vendors: Adobe, EMC, Juniper, Microsoft, Nokia, SAP, Siemens and Symantec.
The paper lays down 36 goals Agile teams may wish to pursue while working on software products and is meant to supplement an earlier best practices paper written by the group. These goals are gleaned from the experiences of coding teams within SAFECode’s members as effective ways to approach Agile coding.
Called stories, these specific goals are written in plain language and from a particular perspective. For example, one story reads: “As a(n) architect/developer, I want to ensure AND as [quality assurance], I want to verify that cross-site scripting attacks are prevented.”
The story is accompanied by a set of tasks to accomplish this goal, each one marked with the category of team members who should work on each task. One task associated with the story in the example above is directed toward developers and testers and reads: “[D/T] When generating dynamic web pages, filter the input for any browser-executable content that is not intended (for example, from user-originated fields in a database). Consider all forms of input of content that might eventually be presented to and consumed by a browser, like events generated outside the system, log messages, arguments in a URL, form field values, etc. Perform this filtering at server-side, close to use.”
Depending on how much is accomplished toward that goal after the first sprint, it may remain as a task for the next one or be refined to address new issues that crop up. The task list is meant to guide Agile teams toward accomplishing goals that will lower risk of vulnerabilities, but not by setting down a rigid set of steps that may not be applicable to all projects.
“Incorporating security in Agile was a challenge,” for SAFECode member companies, Bonver says. “They decided to share their experiences, what they had success doing.”
Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com