Sprint #2: How bad can it be

Welcome back to the second sprint of OneHourAppSec – how did you get on with Sprint 1?

This sprint we build on the foundation we built in sprint 1 and face one of the most confronting parts of securing software – it will probably go wrong.

It’s ok, don’t panic. 

This isn’t a reflection of you or your software, it’s just math. There are many ways that software security can go wrong so statistically, we will all see a security issue at some point.

This sprint we come to terms with this and take the drama out of it by preparing for the (somewhat) inevitable by:

Understanding what we should do if something does go wrong (from a security perspective)

Understanding how to determine how serious an incident is in our context.

There is a lot to do but we will do it in small chunks to make it more manageable. Let’s get into it 👏


📽️ [VIDEO] Introducing Sprint 2 (5 minutes)

Welcome to sprint two and the world of incident response.

📽️ [VIDEO] What is a Security Incident and why do they matter to software teams? (5 minutes)

We dive into what security incidents are, how they typically work and why they matter to software teams like yours. 

📑 Find and review your organizations incident response plan (20 minutes)

Does your organization already have an incident response plan? If so, it’s a great time to go find it and have a look.

  • Does it mention software related security incidents?
  • Does it have details of how your software teams would be notified if there was an incident in progress?

While this may not be your document, reading what has been built before helps you understand what support and process is already in place.

Remember to add any thoughts, suggestions or findings you have to your Security Debt tracker.


If your organization doesn’t have an incident response plan, you can find some easy to follow guidance for creating your own from CERT NZ.

📽️ [VIDEO] How bad is it? How to decide how serious a software security incident is (5 minutes)

Incidents happen all the time but incidents are not all equal. Learn how to decide how serious a security incident is for your organization or context.

📑 Create your own Incident Severity Definitions (25 minutes)

Now that you understand the process, let’s create reusable incident severity definitions for use in your team. We even made you a template to help you get started.

Share the Post:


More Posts

Sprint #7: Getting on with an SBOM

This sprint, we’re going to build an artifact to support the work we did in sprints five and six. In the last two sprints, we looked at how we choose technologies to integrate into our software. In this sprint, we will learn about a common way to communicate this list of technologies – the SBOM (or Software Bill of Materials). Increasingly required for regulation, compliance, and even to sell to larger organizations, your SBOM may end up being more important than you realize.

Sprint #6: Looking after your libraries

This sprint we look at what happens to those libraries once we have them in place and what we need to do from a security perspective to keep them and us safe.

Understanding why 3rd party components can pose a risk to our software supply chain

Examining a 3rd party library from a security perspective and learning what to look for.

Putting a lightweight process in for accepting new components into your stack.

Start your free trial today

Sign up for a 14-day trial of our team plan and invite your whole team. 

No credit card required.