Storyboard: Incident avoided with DevSecOps

Read the storyboard carefully from start to finish. Pay special attention to the sequence of stages where security controls are applied and to the concrete examples of vulnerabilities detected. After reading, be ready to explain which control identified which issue and what remediation was applied. This knowledge will be directly tested in the next quiz.

Imagine a small online bookstore called ReadMeNow. The company has fewer than twenty employees, but customers are located on three continents and expect the site to be available twenty–four hours a day. The owner recently asked the development team to add a "one-click buy" feature so that registered users can purchase any book with a single click from the product page. The story that follows describes step by step how the team nearly introduced a critical vulnerability and how a DevSecOps approach detected and eliminated the problem before it could reach production.

Step 1 – Business request and user story creation
The product owner writes a user story: "As a logged-in user, I want to click one button and immediately purchase the displayed book, using my default credit card." Traditionally, developers would start coding straight away. Instead, because the company adopted DevSecOps (Development, Security, and Operations working together), the team holds a short threat-model mini-workshop. During this workshop they draw a simple data-flow diagram on a whiteboard. They quickly identify two sensitive assets: the customer’s stored payment token and the order database. Potential threats listed include credit-card token leak, price manipulation, and excessive authorization (a user buying for another account). The team adds acceptance criteria that cover security: "Only the authenticated account’s default payment method may be charged" and "Input price must be taken from the server-side catalogue, never from the browser."

Step 2 – Developer starts coding with built-in security guidance
Sara, the developer, creates a new branch in the version-control system. Her integrated development environment contains secure-coding plugins: one plugin shows contextual tips each time she writes a database query; another forces prepared statements rather than string concatenation. When she attempts to copy old code that builds an SQL command manually, the plugin highlights the line in red and explains: "Potential injection. Use the OrderRepository.create() method instead." Sara corrects her code immediately.

Step 3 – Pre-commit hooks
Before she can push the branch to the shared repository, a pre-commit hook runs three automated checks locally:
- Linting and style rules to keep the codebase readable and prevent hidden logic errors.
- Static Application Security Testing (SAST), which scans the modified files for patterns associated with common weaknesses, such as broken access control or injection flaws.
- A custom script that checks whether any secret keys have been added to the code.
All three checks pass because Sara followed the guidelines.

Step 4 – Pull request and peer review supported by security bots
Sara opens a pull request. Two colleagues perform a code review. At the same time, a bot called Guardian posts automated comments. One comment points out that the new endpoint /buy-one-click lacks an explicit rate limit annotation. The team has agreed that any endpoint handling money must be limited to ten requests per minute per user to reduce the impact of brute-force attacks. Sara adds the annotation and pushes an update.

Step 5 – Continuous Integration pipeline kicks in
Once the pull request is approved, the Continuous Integration and Continuous Delivery pipeline (that is, the automated sequence of build, test, and deployment steps) starts on the build server. The pipeline is divided into several gated stages:
1. Compile and unit tests
2. Static Application Security Testing with a company-approved scanner
3. Software Composition Analysis, which inventories all external libraries and checks them against vulnerability databases
4. Container image build with a hardened operating-system base layer
5. Dynamic Application Security Testing (DAST) in a disposable staging environment
6. Integration tests, including regression tests for previous bugs
7. Compliance checks ensuring required licenses are respected
8. Manual approval by the release manager only if all previous stages are green

Concrete example: During Software Composition Analysis the scanner flags version 2.7.9 of the Stripe payment Software Development Kit. The scanner links to advisory CVE-2023-12345 describing a remote code-execution flaw exploitable when the library processes malformed JSON input. Because the pipeline workflow specifies “vulnerabilities with severity high or critical break the build,” the pipeline stops automatically, preventing further stages from running. The developer replaces the dependency with version 2.7.10, which contains the security patch. She documents the change in the pull request and re-runs the pipeline. This time the stage passes.

Step 6 – Dynamic tests reveal a logic error that could have become an incident
In the disposable staging environment, the Dynamic Application Security Testing tool performs authenticated scanning. It generates test purchases with random prices and detects that the client-side JavaScript still sends the price chosen by the browser, even though the server later overwrites it. A policy in the scanner treats client-controlled price parameters as a medium-risk issue. The DAST report appears as a comment on the build summary. The team decides that medium risks affecting monetary values must be fixed before release. Sara removes the price parameter entirely from the JavaScript call and relies on the product identifier only. She pushes the fix, the pipeline restarts, and the DAST stage now shows zero findings.

Step 7 – Deployment to pre-production and chaos test
The pipeline automatically deploys the release candidate to a pre-production environment that mirrors production. A small chaos experiment intentionally degrades the payment gateway latency to two seconds. Observability dashboards (metrics, logs, traces) show that the one-click purchase endpoint continues to respect the ten-second timeout and fails gracefully, returning the error "Payment temporarily unavailable" without leaking any internal stack trace. This confirms resilience and secure error handling.

Step 8 – Release and continuous monitoring
After... (download to read the rest 👇)