Cigital: a new Agile (Security) Manifesto

Application security and software security consulting company Cigital says that its time for a new layer to be placed on top of the Agile Manifesto — a set of principles that was released in 2001 as a reaction to documentation-heavy software development practices.

The name of that new layer? It’s the Agile Security Manifesto.

The firm argues that security is seen as something separate from and external to software development. Cigital wants to change the approach to building secure software within an Agile methodology.

According to a new white paper from Cigital, “Security is often focused on testing and security activities are often conducted outside and apart from the   software development process. As a result, the outcomes of security activities are presented in documents and outputs that do not naturally fit any of the software development activities.”

Rely on developers and testers more than security specialists

While experienced security specialists are valuable, few agile teams have dedicated security specialists. This means that most of the time, security must be done by the same team that does the rest of the software development.

“Continuous Integration/Continuous Deployment (CI/CD) can’t wait for an external security review before the code moves forward on the assembly line. Security must be an integrated part of our everyday development and testing of code,” says the firm.

Small, iterative changes evolve software security over time

The following text is presented as an excerpt from the original paper by Cigital.

We should focus on business value of software and achieving the software’s mission, not adding or implementing security features. As much as possible, this should be intrinsic to what we do through secure-by-default frameworks, rather than explicit calls to security libraries or custom implementations of security functions. The implementation of security features such as authentication controls, password storage schemes, and cryptographic algorithms is best left to experienced professionals whose day-to-day work focuses on these particular topics.

It is tempting to hunt for all the security vulnerabilities we can find, mitigate what we identify, and call the software “secure” afterwards. To build secure software we need to consider the risks to the business, the users, the data, etc.

We try to minimise those risks by building the software securely. Sometimes all we have to do is fix a bug. But often it is more complicated. Risk management is about figuring out the right way to deal with a risk. Maybe we write some code; maybe we monitor and react to bad behaviour; maybe we use legal and contractual controls instead of technical controls. We favor a holistic view of things that could go wrong, instead of distilling security” down to a giant list of individual bugs that need to be squashed.

The Agile Manifesto says to favour “Working software over comprehensive documentation”… so they are not abandoning documentation entirely. Likewise, the Agile Security Manifesto says we favour risks over bugs; but, that doesn’t mean we abandon finding and fixing bugs.

1 agulekjoih