Securing Software Development: Integrating InfoSec and Scrum Teams

As a manager or a software engineer working with Scrum methodology, you might be very well aware of the underlying principles of an effective workflow that maximises the outcome of efforts by establishing a universal pipeline for feature requests from business to the market and back. But it shouldn't be surprising if not all the parts of your organisation follow the principles of the Agile process and Scrum in particular. Each organisation unit, each part of the overall process should be free to choose the approach that works the best.

In a situation when requirements for a development team using Scrum come from external sources, it's critical to establish correct expectations on input and output of the sub-processes driven by different yet interacting teams.

The key to creating successful process here is understanding that a robust Scrum team operates as a streamlined and effective pipeline, efficiently translating formulated business requests into tangible outcomes. However, when these requests arrive in unfamiliar formats, a disconnect emerges, hindering the realisation of objectives. In the worst cases, that might significantly impact feature delivery (for the whole team) due to prolonged investigation and/or implementation.

In this material, we will consider a specific case of addressing information security-related work in the most effective manner when requests for such work are coming from outside the team. We will set expectations on processing vulnerability reports to seamlessly flow the items to Scrum backlog, facilitating this integration into established operational procedures. Addressing this disparity is essential to enable the team to manage these requests without impeding other items in the backlog.

Vision

The core solution revolves around defining precise communication expectations across multiple stakeholders - InfoSec professionals, IT managers, and the development team itself. This structured approach mirrors the concept of the adapter pattern, transferring its essence from code implementation to real-world procedures.

Clear communication plays a pivotal role, with InfoSec leaders gaining insights into the expected format for business requests, while the development team learns how to communicate changes' outcomes. This mutual understanding empowers InfoSec professionals to give the right initial impulse to effective security remediation work and maintain an updated security state in both internal and external documentation.

We're going to utilise the capabilities of a proficient Scrum team to implement change requests that follow the requirements the team puts to input (in a form of Definition of Ready or a similar principle) by bridging the gap between teams following different approach to work organisation.

Solution

The solution lies in following a comprehensive, step-by-step guide that navigates the journey from a fresh security report to Scrum backlog stories and vice versa. This seamless integration ensures minimal disruption to the team's processes and capitalises on their comfort zone and work habits.

1. InfoSec team: Initial report analysis. The initial holistic report for one or multiple projects undergoes dissection by an InfoSec specialist, segregating it into independent units of work. This step ensures that vulnerabilities can be prioritised, estimated, and planned independently, fostering several benefits:
   • Parallel investigation and resolution of multiple items.
   • Prevention of low-criticality issues obstructing more critical tasks.
   • Enhanced accuracy in estimating smaller tasks, minimising uncertainty.
2. InfoSec team: Issue categorisation. Issues are classified into two categories: infrastructure issues and application issues. Infrastructure concerns are directed to DevOps or Ops teams, while application issues progress through the provided guide.

3. InfoSec team: Story Creation: Drafts for individual vulnerabilities translate into user stories within the chosen task management system. These stories are assigned to a delivery manager or another responsible individual who is familiar with both the system and team processes. Story creation emphasises several key points for the team:

   • Background Information: Detailed understanding of the vulnerability's nature, affected components, and contextual conditions.
   • Reproducibility: Steps for replicating the issue in a controlled environment, vital for QA and automated testing.
   • Description: Recommendations for addressing the problem, suggesting common approaches. When the solution is unclear, the story's objective is to identify a solution.
   • Acceptance Criteria: Criteria defining successful vulnerability resolution - what we should see to say that we have achieved the goal. These stories are systematically labeled, tagged, or grouped for streamlined accessibility.

4. IT Manager: Oversight. A delivery manager reviews the created stories, ensuring they meet the outlined requirements. Additionally, they assess the need for further task breakdowns, particularly for less atomic requests.

5. IT Manager: Ensuring System Alignment. The recommendations for vulnerability addressing are evaluated against the system's perspective. If necessary, the selected strategy is adjusted to align with the system's values and patterns. Examples include:

   • Addressing verbose error messages in a mobile app by updating the backend API.
   • Consolidating updates to a dependency by upgrading to the current version during the current process instead of the minimal recommended one. The delivery manager ensures this alignment is communicated effectively to the product owner and team, with information enabling the identification of issues throughout the application.

6. IT Manager. Assignment and Monitoring. Stories are assigned to releases based on vulnerability criticality, and tasks are allocated to corresponding teams. A dashboard or filter that presents tagged vulnerability remediation tasks is required at this stage, providing visibility on statuses and release timelines. This process allows for real-time monitoring and adjustments for both IT manager and InfoSec team.

Result & Beyond

The structured procedure ensures that stakeholders can operate within their preferred formats and methodologies while seamlessly integrating security concerns. This approach minimises the impact on the team's ongoing plans, as security issues are addressed with minimal disruption.

This methodology also minimises the risk of unexpected challenges when addressing vulnerabilities. By tailoring recommendations to the project situation, the likelihood of encountering unforeseen obstacles is significantly decreased.

The InfoSec team benefits from real-time visibility into project plans and progress, enabling swift reactions to deprioritisation and successful deliveries as their capacity allows.

While the process is comprehensive, avenues for improvement remain:

• Educating InfoSec team and other peers about Scrum methodologies fosters better story creation.
• Educating the Scrum team on InfoSec team's priorities enhances understanding of the requests and more accurate issue addressing.
• Involvement of senior developers in processing stories streamlines the process and helps scale the process when the vulnerability reports cover multiple projects.
• Measuring lead time of the security-related requests in your projects must lead to well-informed decision on claimed remediation time for security vulnerabilities that might lead to establishing a vulnerability remediation SLA if it hasn't happened yet.

Conclusion

Within our organisation, this process has been helpful in rapidly addressing security concerns while maintaining focus on project innovation. We welcome your thoughts on this approach, proposed enhancements, and any additional recommendations or queries.

Let's save time for beautiful innovations through using well-optimised processes for routine tasks!