Security issues in SCRUM

You may need to be a little more specific with 'security in scrum' to get some good answers that will help you.

I am going to assume you mean something along the lines of encrypting the data, which I think would be a task in the user story and it would also be part of the acceptance criteria. It is something that most likely should be added to the teams definition of done and done in full as the team goes. You don't want the concept of 'building in security in the final 2 sprints' - because everything you have done up until that point isn't potentially shippable and you don't have the security you need.

As Tims say, security requirements should be (as all other non functional requirement) agreed on in the Definition Of Done. This doesn’t mean the DoD is a 1000+ page reference guide.

It can be as simple / informal as:
- we adhere to our company security policies defined in chapter 3 & 6,
- our product is capable to withstand general threads, but no provisions are made to handle a specific concentrated attack.

The key is that it is transparent for the Development Team, The Product Owner and possible the stakeholders what is covered. For a security critical application it must be possible to refer to an internal or external reference.

> I'm wondering how security issues are
> supposed to be handled in SCRUM. 

The key consideration is whether or not the requirements can be implemented and validated by the Development Team. If they can, then they may be added as PBI's (e.g. so-called "abuser stories") assuming that regression testing can be automated and is therefore scalable. It's also reasonable to add constraints and observations to the Definition of Done. These may assert the qualities of security with which each increment is expected to conform.

Security requirements which cannot be implemented and verified by a Development Team belong neither on the Product Backlog nor in the Definition of Done. Examples may include assertions about the penetration of certain live systems, recovery, failover, and concerns that involve security support following a release. These often relate more to the qualities of the organizational environment into which the increment will be deployed, as opposed to the qualities of the deliverable increment itself.

Hello All,

I would like to raise this topic, due to some misunderstanding in my mind.

Lets say that a developer is approaching the Scrum Master, and informs him about his security issues concerns. 
How would we expect the SM to react in such occasions?

From what I understand, the ways for the Scrum Team to ensure satisfaction of security concerns , is to add them to the DoD, and having them added to the Product Backlog as a PBI.

According to the scenario above, does it mean that the Scrum Master should advise the developer to share his security concern with the Scrum Team, or wait till the next Sprint Retrospective, and raise the concern, which will lead to adding it to the DoD?

Some explanation would be highly appreciated.
Thanks in advance !

As SM I would advise them to take it to the team. This time and in the future. SM doesn't need to be the middle-person or broker in raising such things.

DoD pertains to the Increment and could possibly include insuring that security scans are completed or that no security issues are knowingly introduced etc. to help protect the integrity of the product when integrating into the Increment. Sprint Retrospective is a good place to review and update the DoD. That said, if a need to refine (strengthen) the DoD presents itself, there is no need to wait and put off the adaptation. 

If there is an immediate security concern that needs to be addressed, beyond strengthening the DoD, waiting until Sprint Retrospective could be dangerous and impactful. Sprint Retrospective could be days or weeks away. Bringing immediate attention to the security concern supports transparency with which the team can inspect and adapt as needed to mitigate the concern based on what the team decides.

Hi Ryan,

Thank you for the good explanation !