W7_ISSC636_Example

Example:

DevSecOps Works Only When Developers Don’t Avoid It

Select the Start button to begin

Start

Select the Listen button to play the narration for this slide

Navigation

Listen

buttons

Use the following buttons to navigate through the course content

Listen

Play the audio for the current page

hOME

nEXT

PREVIOUS

Return to the previous page

Return to the course home page

Move to the next page

home

next

previous

Select the Listen button to play the narration for this slide

Listen

Hi, I’m Caleb Turner, and I want to tell you about a DevSecOps turnaround that happened only after we admitted something uncomfortable: our security process was technically “correct,” but it was designed in a way that made developers avoid it.

home

next

previous

Select the Listen button to play the narration for this slide

Listen

I was at EverCrest Solutions, a company building a SaaS platform for project budgeting and approvals. We shipped features fast, and our engineers were proud of that. Security, on the other hand, was treated like the team that showed up at the end and said “no.”

home

next

previous

Select the Listen button to play the narration for this slide

Listen

The pattern looked like this:

• Developers built features
• Security reviewed late
• Security found issues
• Release dates got threatened
• Teams argued
• Exceptions were granted informally
• And the same problems came back next sprint

We weren’t improving. We were looping.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

The moment that forced change

A minor incident became the wake-up call. We discovered an API endpoint that allowed excessive data access when a certain parameter was manipulated. It wasn’t exploited widely, but it was real, and it was embarrassing because it was a predictable authorization issue.

home

next

previous

Select the Listen button to play the narration for this slide.

Listen

The moment that forced change

Leadership asked: “How did this make it to production?” And the honest answer was: the SDLC had no reliable security feedback loop.

We had scans, but they weren’t enforced. We had code reviews, but they weren’t guided. We had policies, but they weren’t translated into pipelines.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Step 1 — Treat the pipeline as the control plane

Instead of trying to convince developers with presentations, we changed the environment. We made the pipeline the place where security became unavoidable—but also fast and fair.

We implemented:

• Secrets scanning on every pull request
• Dependency scanning (SCA) with severity thresholds
• Static analysis (SAST) for common high-risk patterns
• Infrastructure-as-code scanning for cloud misconfigurations
• A policy gate that blocked merges when critical issues were introduced

But we didn’t just “turn on blocking.” We designed the workflow.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Step 2 — Make security feedback usable

Developers complained at first, not because they hated security, but because findings were unclear and slow. So we did three things:

• We tuned rules to reduce noise
• We added guidance: what this finding means, why it matters, and how to fix it
• We made sure scans ran quickly enough that PR feedback felt like normal development, not punishment

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Make security feedback usable

We also created a severity agreement:

• Critical and high issues block merges
• Medium issues require a ticket and a fix timeline
• Low issues are tracked and bundled into hygiene work
• Exceptions require approval, justification, and expiration

Now security wasn’t a surprise. It was predictable.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Step 3 — Fix the “exception culture”

Previously, exceptions were like informal favors. That’s how risk gets hidden. We introduced an exception workflow:

• Documented request
• Risk justification
• Compensating controls
• Owner
• Expiration
• And a review checkpoint

It felt bureaucratic for about a week—until people realized it stopped arguments. There was a clear path, and leadership owned the decision.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Step 4 — Close the loop with learning

We didn’t stop at pipeline gates. We added feedback from production:

• Alerts on abnormal authorization patterns
• Monitoring on key endpoints
• Metrics on recurring vulnerability classes
• Post-incident reviews that produced coding guidelines and test cases

This was the biggest shift: security became a learning system, not just a gate.

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

The outcome

Within two months:

• Critical issues stopped showing up late, because they were caught on PRs
• Remediation time improved because owners were clear
• The same vulnerability class recurred less because guidelines and tests improved
• Releases got smoother because security became part of “normal work”

home

next

previous

Listen

Select the Listen button to play the narration for this slide.

Takeaway

DevSecOps isn’t “security tools in CI.” It’s designing a delivery system where security happens automatically, feedback is fast, and evidence is created every time you build and deploy.

The goal isn’t to slow development—it’s to prevent security debt from becoming a crisis.

home

next

previous

Select the Listen button to play the narration for this slide

Listen

Congratulations!

You've successfully completed the example

home

previous