We’ve all been there.
We’re busily going about our work, when suddenly we notice something odd. Maybe it’s a badly thought out permission policy, maybe it’s some unprotected URL configuration that could be used to get an EC2 instance to spill its guts , but whatever it is, it smells.
But you’re knee deep in your own task, so you wearily go to JIRA, click ‘Create New’ and enter in the most perfunctory ticket description possible. And off it goes, your new little ticket, to reside deep within the project backlog, collecting crust with the other non-function-requirement tickets. Hey, business is business, and business needs features!
Or maybe you don’t do anything at all. ‘Cause why bother?
Either way, the problem never gets looked at, never gets evaluated and never gets fixed.
Not every security risk is an immediate threat, nor does every problem need work scheduled to fix it. Knowing the risk, and getting the appropriate sign off when that risk is acceptable, is just as good if not better than trying to fix the problem; no system can be one hundred percent secure, and it’s up to the business to decide what assets are valuable to them and what level of security they need.
The problem is getting a good workflow that allows you to have an overview of risks for a project, and to escalate and action them effectively. This is especially important for multi-team projects, where each team may have their own Scrum or Kanban flow, their own managers and reporting structure, and their own internal politics. Your usual Agile setup is also geared toward concrete bits of work, not considering/escalating/actioning abstract risks.
Therefore it’s useful to have a separate appsec project or workflow that’s outside of the day-to-day workflow, where risks can be logged and processed, with lead developers (or security focused developers) and managers invited. A typical workflow would look like this:
- Risk Ticket raised by one of the teams developers; this ticket should be as much in the abstract as possible (at this point it’s wasteful to start looking at the concrete fix)
- Ticket reviewed by the lead developer e.g as part of weekly review
- The lead talks to the product owner or similar manager about the risk posed, and possible solutions.
- The product owner decided whether it’s worth scheduling the work for the fix, or whether it’s an acceptable risk.
- If it’s an acceptable risk, the owner closes the ticket.
- If it’s something that should be fixed, then a new linked ticket in the teams actual ‘day-to-day’ workflow project is created, with concrete specifications on how to fix it, along with a priority. This is a work ticket, and separate from the original Risk ticket.
- This new ticket is then fixed as part of the usual development process.
This may seem like overkill, but it really helps with larger projects especially when applied across teams, as it bypasses a lot of the usual siloing that you get in big projects and allows for cross team threats to be addressed.
More importantly, it empowers all developers to raise security concerns that they spot, safe in the knowledge that these concerns will be seen, evaluated and dealt with appropriately.