If we give a security auditing company a working system, and ask them to audit i

Question

If we give a security auditing company a working system, and ask them to audit it, and only do that once during a project because it's expensive, this is basically waterfall.

How can security auditing be integrated into an agile project without turning it into a waterfall project, and thereby introducing audit fail risk?

What we want to do is know the detailed security requirements upfront, so that we can create stories for them (and/or integrate them into existing stories), and write automated tests for them which give us some degree of confidence that the security requirements have been fulfilled. This is the agile way.

But the trouble is, if you don't know exactly what the first production deployment is going to look like until soon before deploying to production, because it's an agile project, you can't tell a security auditing company what exactly it's going to look like. So they may tell you "the number of possible vulnerabilities in an arbitrary system is extremely large, so we have to know what it looks like to narrow it down, so come back when you know what it's going to look like, and then we will give you the requirements". In that case, you can't do it in an agile way.

Explanation / Answer

As others have suggested, you can build in stories about security. And I would certainly encourage you to do that.

But if you're talking about an external team coming in and spending several weeks doing an audit ... that, it seems to me, is more about agile than security.

I know that agile places a heavy emphasis on shipping frequently -- after all, how are you going to shorten the feedback cycle if your software isn't in customers' hands? But for many organizations, releasing every 2/3/4 weeks simply isn't a option. Or they have a lengthy QA/QC review process and the QA organization isn't ready to go agile. Or they have other certification requirements (e.g. ISO) which don't fit into the agile lifecycle.

Consequently many agile teams discovered early on that they needed to decouple their releases from their iterations or sprints.
That is, instead of promoting to production, you promote changes to an environment dedicated to security / QA / whatever. When the code has been certified there, you promote it to production (or to the next gate).

If you've been building in "misuse" stories, presumably your defect / issue list should be short.

If a defect is found, it can be put into the backlog or prioritized for an immediate fix, depending on its severity.

Of course the extra environment isn't free ... but in my experience it's cheaper than the alternatives (which typically result in teams stepping on each other's toes).

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.