Definition of done, ready — and security

We all do some kind of agile software development these days. While people may argue over the benefits, a large number of software development houses are transforming themselves to “go agile”. These transformation periods are generally chaotic and there may be difficulties in following an organisation’s security policy when implementing agile.

In this post I will explain how some (not all) of the security requirements can become part of Definition of Done as well as Definition of Ready.

I have worked in a organisation which was going through a transformation period to use Scaled Agile Framework (SAFe) for agile software development. We updated our DoD and DoR criteria and managed to include a few security requirements set by the product security policy of the organisation. Thereby adding a few security aspects to a shared understanding within the product team.

Image for post
Image for post
Photo by Daria Nepriakhina on Unsplash

What is DoD and DoR?

Definition of Done
aka DoD is a criteria that must be met if something is considered done-done. This is generally applied to an increment (e.g. a sprint) or a user story. For example, at the end of a sprint when the team closes the stories, they go through the definition of done criteria to see if each story can be closed (i.e. considered done-done). A DoD criteria may contain items such as — documentation done, code review done, security criteria met, quality criteria met, etc.

Definition of Ready
aka DoR on the other hand is a criteria that must be met before something can be considered ready-ready to be worked on. For example, during a spring planning (or program increment planning in many cases), when the team sits to plan which stories can go in what sprint, they typically only entertain stories that are marked ready-ready i.e. have satisfied the criteria of DoR. A DoR is gone though when a story is discussed typically during the backlog refinement sessions or when a feature is discussed by the stakeholders. A DoR criteria may contain items such as — acceptance criteria defined, security criteria defined, dependencies identified, story points roughly estimated, etc.

DoD and DoR can be at multiple levels (for example in SAFe). In general I have seen the following levels of DoDs:

  1. Story level
  2. Feature level

Dissecting the security criteria for DoD and DoR

Determining which security requirements to consider for each of the DoD and DoR can be a challenge. It would be counter productive and confusing for the team when they have a huge checklist of items many of which may not apply to the DoD or DoR criteria. The general rule of the thumb is that consider only the security criteria that is repeatable and criteria that can generally be agreed upon within a team or a set of teams.

Just as a note, I am considering the typical security engineering cycle— threat analysis, security architecture, secure coding, security documentation, security hardening, security testing, security reporting.

What security requirements to exclude from DoD or DoR?

Security requirements that must never be a part of DoD or DoR include items that can be considered as . Simply because such requirements are not recurring and are easily implemented as separate features and eventually stories. Few examples include features such as User authentication, SSO, login page, etc.

One must also exclude things that can be easily automated. These include the acts of performing security code scanning, running dependency checks, running licence checks, etc.

Lastly, exclude those items that can be added to the acceptance criteria. For example, a DoD shouldn’t contain “relevant permissions for access control implemented for the story”. Such requirement should go to the acceptance criteria because it may be different for each story.

What security requirements to include in a DoR?

I would typically put criteria in the DoR that would trigger an updating of the acceptance criteria or the description of the story/feature to “consider” security.

At the feature level,

  1. A threat and risk analysis of the feature must be done and the acceptance criteria is updated with mitigation requirements (e.g. hardening requirements, access control specific requirements, etc.)
  2. Security testing criteria should be identified in the acceptance criteria. E.g. perform denial of service testing (if the feature is likely affected by it).

At the story level, you can have the same criteria (if needed).

What security requirements to include in a DoD?

My suggestion is to put items in the DoD that involve “check and take corrective action”. Other things include items of which a team must have a collective understanding (such as, the code must follow secure coding guidelines)

At the feature level,

  1. Acceptance criteria satisfied (so that all security criteria mentioned in the acceptance criteria is also met).

At the story level,

  1. Acceptance criteria satisfied (so that all security criteria in the acceptance criteria is also met).
  2. Code scanning results are such that security coding guidelines are followed.
  3. Dependency analysis results are such that no vulnerable libraries are used in the code specific to the story.

Note that emphasis on the word “checked” above. Here, it is assumed that the activities of code scanning and dependency analysis are already automated. The criteria is to rather the results of the action, and take appropriate action to satisfy requirement. Also ponder upon why I placed the code scanning and dependency scanning items at the story level instead of the feature level.

The DoD criteria in general is considered blocking, meaning that, if not satisfied, the item in question (story/feature) is considered incomplete.

If you have reached here, thanks for reading. Remember that this post is only a guidance and not an absolute solution. Security is tackled differently in different organisations and most of the times there is no one-fit-for-all solution. Hence, it is recommended to read more literature on this topic before taking concrete decisions.

Written by

I am a computer security enthusiast living in Finland

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store