In this article, we will address some points that can help you understand why sprint security planning should also be considered important and should be part of a Product Owner’s dynamic.
When we talk about software development, we always hear that one of the big security problems is the view that “security is thought of later, let’s deliver the application first.” This has a number of problems, but today we are going to talk about a another point that few are aware of: Software Supply Chain.
The thought that security is a point that can be worked on later not only increases your list of things to solve – known as a backlog – but also ends up undermining your client’s confidence in your work.
Relevant data
A survey conducted by CloudBees shows that 95% of C-Level executives are more concerned with securing their supply chains for the production of their applications. However, even with this view changing, we still have a long path to run.
A good example was when events involving Log4J led several development teams to carry out searches for affected components. Clearly the use of tools using SBOM concepts would have solved this point very quickly and practically.
Yet, in another survey, this time carried out by Venati, we have 61% of executives who understand that concern with Software Supply Chain should be the responsibility of the IT team, and we have 31% understand that this responsibility should be the responsibility of the development teams.
Furthermore, 94% of these same executives understand that the vendor should be punished for these weaknesses in their systems.
Now we can understand that we are facing a very clear situation: software security must be incorporated into the development process as early as possible. Planning the security aspects of a software can allow companies to build their solutions in a more secure, practical and effective way.
Security during sprints – How to plan
Now that you got the general context, you might be wondering: what is the best way to plan security during sprints?
The agile model, by definition, can be contrary to the risk mitigation process or even to the production of security coverage. Agile models use Scrum as a framework. Activities and tasks are broken down into activities that can be completed within a fixed time, called sprints.
All activities to be developed come from a list called backlog, which by definition is a list composed of functional and non-functional requirements. From this list, activities are taken out and worked on, and when the sprint is over, the cards are put as closed. This is to show progress in the application building process. In this scenario, the most important element is time!
When security is placed within the process, and cards are created to represent these needs, it is possible that the backlog will be impacted, having many other activities, and that, within the determined time, closing those activities would be unfeasible.
This is the point: we have arrived at a point where we should start talking about the importance of having Product Owners really interested, focused and proactive when it comes to application security.
Where would a Product Owner act in an SDLC?
First let’s remember what the role of a Product Owner is.
Within the development process, the Product Owner or simply PO has the function of defining the backlog, and also, converting user stories or even the use case of the product into functional requirements and non-functional requirements.
When, for some reason, the Product Owner brings a security point to the sprint, this is usually given less importance than the definition and execution of functional or non-functional requirements.
Also, we have a very strong cultural aspect: it is normal for development teams to have the understanding that security aspects must be validated and seen by specific teams, and that others can carry out code review activities, for example.
But they forget one very important aspect – and for that I will try to answer first, this time, with a question:
So what would be the main focus of agile development models? Wouldn’t it be, among many, time gain for development?
Well, if we think that other teams should worry about security and then carry out the tests, what would happen with the vulnerabilities and/or coding errors found? Wouldn’t these go back to the development team to fix? And what happened to the time that was gained in the first moment?
And hey, I can answer it: it was lost with the rework!
Time optimization
So, answering the prior topic’s question, the PO should be concerned with understanding the needs of creating stories and use cases, but should also be concerned with including security requirements in these points, already thinking about really taking advantage of the best possible way. your team’s time.
So again it all comes down to an effective and efficient use of time! And you might be wondering now: Okay, but what would be the real benefits of my Product Owner planning security in sprints?
Well, I’ll try to list a few here.
I don’t know about you, but for me it’s pretty clear that one of the main gains would be regarding time. We would have a lot less rework. We would need to work less on correcting points that clearly could have been developed correctly.
Another point that I see as very clear is regarding compliance postures that would already be met in the early stages of a development, this could avoid a series of problems, if everyone knew what they really should build.
I see another one: this type of attitude would demonstrate to your client a vision and concern about having a secure product, which focuses on maintaining their privacy, I think this in itself is a very interesting thing to be put here, but let’s in front of.
Last but not least: you, as a developer, would already build software with solid security foundations.
But as Product Owner, how can I prioritize security during sprints?
Well, I see two ways that this can be presented within the development process.
The first is to imagine that you will have a dedicated time for sprint security planning. At this point, you must identify everything that will be carried out within the sprint, user stories or even product use case, and already build the security vision necessary for the sprint, that is, we will have exclusive security sprints where we will have code review, design review or architecture and even for building security requirements.
The second model I think of is when security requirements are included in regular sprint activities. Here, the normal process of planning activities takes place, with the definitions of requirements that will be delivered. But in this case, we will also have activities focused on application security.
Well, regardless of whether you are going to use one of the two views that I put here, one thing cannot be ignored, Product Owners can no longer ignore the security of applications, they need to be part of their daily lives.
And you, what do you think about this?
