AppSecEU 16 - Dinis Cruz - Using JIRA to manage Risks and Security Champions activities

### Overview In this AppSecEU 2016 presentation, Dinis Cruz presents a pragmatic, objective framework for managing application security (AppSec) by embedding risks, unintended behaviors, and security testing into standard development tracking workflows using JIRA (or alternatives like GitHub). Cruz argues that AppSec should not operate as a tax on developers or an ivory-tower blocker. Instead, AppSec teams should adopt a developer-aligned posture where teams say "yes" while clearly articulating the consequences, risks, and "pollution" of architectural decisions. By structuring AppSec activities around dedicated security champion networks, test-driven development (TDD), and an unambiguous two-path JIRA workflow (fixing vs. accepting risk), organizations can make risk ownership rational, measurable, and owned by business stakeholders rather than developers.

### Key Topics - **Reframing AppSec and Risk:** Cruz defines application security as understanding and managing unintended application behaviors, aligning it directly with non-functional software requirements and quality. He treats any unintended behavior, unanswered architectural question, or vulnerability as a "risk" and compares unaddressed flaws to environmental "pollution" rather than technical debt. - **Scaling via Security Champions:** Scaling security across large organizations requires embedded champions or advocates within each product team who allocate roughly one day per week to security tasks, weekly syncs, and testing improvements. Champions are non-management individual contributors without unilateral decision-making authority, acting as the primary security liaison and QA partner. - **The Two-Path JIRA Risk Workflow:** Security issues enter a dedicated JIRA project (e.g., named `RISK`) separate from standard product backlogs to avoid political friction. Tickets cannot languish indefinitely in a backlog; they must follow one of two mutually exclusive paths: 1. **Fix Path:** Issues move from `Allocated for Fix` to `Fixing`, followed by explicit verification through tests (`Test for Fix`) before being marked as `Fixed`. 2. **Risk Acceptance Path:** When an issue is not prioritized for fixing, it moves to `Request Risk Acceptance`. Business owners must physically click `Accept Risk` to establish accountability, followed by security/CISO approval (`Risk Approved`). - **Expiring Approvals and Executive Visibility:** Accepted risks are placed on automated reporting schedules (sent weekly to business owners, CISOs, and CTOs) and carry strict expiration windows (e.g., two weeks to three to six months) to prevent permanent neglect and trigger re-evaluation. - **TDD and Security Tests as Code:** Cruz demonstrates writing unit/integration tests that intentionally reproduce vulnerabilities (e.g., path traversal, remote code execution, denial of service) as passing tests asserting existing behavior. Fixes are verified by updating the test so that it asserts the secure state and remains a permanent regression test. Real-time test runners (demonstrated using Wallaby.js) lock the attack surface, failing immediately when new endpoints or routes are added without review.

### Technical Details Cruz illustrates his workflow using an open-source maturity model tool built with Node.js, AngularJS, and CoffeeScript, compatible with OpenSAMM and BSIMM. The continuous integration pipeline deploys multiple times a day across GitHub, Travis CI, Docker Hub, Docker Cloud, and DigitalOcean, running functional and QA/performance test forks against live test containers.

To demonstrate vulnerability workflows without exposing proprietary flaws, Cruz presents an internal file-editing feature written in CoffeeScript where path parameters allowed arbitrary file creation and traversal. Cruz walked through: 1. Documenting distinct risks in JIRA (path traversal, arbitrary extensions, denial of service via file length, remote code execution, and unauthenticated file writes). 2. Annotating source code with direct JIRA ticket references and TODOs. 3. Creating automated Mocha/unit tests asserting that payloads succeed while the issue exists. 4. Implementing code remediations and flipping the tests into defensive regression assertions. 5. Moving residual accepted risks (such as denial of service via oversized file payloads) through the formal JIRA acceptance workflow.

### Takeaways - **Enforce Business Accountability:** Developers should not shoulder the liability of known risks. Forcing business owners to explicitly click acceptance buttons and transmitting accepted risks up to the CTO/CISO ensures informed decision-making. - **Volume Removes Stigma:** Having hundreds of documented risks in an organization is healthy; teams claiming zero risks are usually the most vulnerable. - **Tests as the Single Source of Truth:** A vulnerability should be demonstrated with an automated test, and a security fix should be reviewed primarily by reviewing its corresponding regression test. - **Lock the Attack Surface:** Integrating real-time continuous testing tools alerts developers the instant a route or attack surface expands, triggering immediate security reviews.