Security Champion in development and DevOps
In Module 2, you implemented quick wins — password managers, MFA, email security. Those protect the perimeter. Module 3 is about protecting what you build.
Most security vulnerabilities are born in code. SQL injection, XSS, broken authentication, insecure API endpoints — these aren't configuration mistakes, they're development mistakes. And they're extremely common because developers aren't trained in security, security teams don't understand development, and the two groups rarely talk.
The Security Champion bridges this gap. You're a developer (or DevOps engineer) who understands both worlds. You can review code for security issues, explain why certain practices matter, and integrate security checks into the development workflow without slowing everything down.
This chapter defines your role in the development process: where you fit, what you do, and how to work effectively with your team.
Why development needs a Security Champion
The disconnect problem
Traditional security works like this:
- Developers build features
- Security team reviews at the end (or never)
- Security finds issues
- Developers have to go back and fix things
- Everyone is frustrated
This fails for several reasons:
Timing: By the time security reviews happen, the feature is done. Fixes are expensive. Deadlines are missed. Pressure mounts to ship anyway.
Knowledge: Security teams don't know the codebase. They flag issues without understanding context. Developers don't understand security. They dismiss findings as theoretical.
Communication: Security speaks in CVEs and OWASP categories. Developers speak in functions and pull requests. Neither side translates well.
Scaling: A security team of 2 can't review code from 50 developers. Most code ships without any security review.
The Security Champion solution
You're embedded in the development team. You write code. You understand the architecture. You know which parts are rushed and which are solid. You attend standups and see what's being built.
This means:
- Security input happens during design, not after
- You can explain why something is risky, not just that it's risky
- Developers trust you because you're one of them
- You can prioritize based on actual risk, not theoretical concerns
You're not replacing a security team. You're extending security into daily development work.
Where you fit in the development process
The shift-left model
"Shift left" means moving security earlier in the development process. The further left (earlier), the cheaper and easier fixes are.
Traditional:
Design → Develop → Test → Deploy → Security Review → Fix
↑
(expensive fixes)
Shift-left:
Design → Develop → Test → Deploy
↓ ↓ ↓ ↓
Security Security SAST Security
input review DAST config
↑
(cheap fixes)
Your touchpoints in the SDLC
1. Planning and design
This is where you have the most impact for the least effort.
- Attend feature planning meetings
- Review technical designs for security implications
- Identify which ASVS requirements apply to new features
- Flag features that need threat modeling
- Add security acceptance criteria to tickets
What you do:
- "This feature handles user file uploads — we need V12 requirements"
- "If we're storing credit cards, we need to discuss PCI scope"
- "This API will be public, let's plan for rate limiting and auth"
2. Development
Be available without being a bottleneck.
- Answer security questions from developers
- Review security-sensitive code changes
- Pair on complex security implementations
- Maintain secure coding guidelines
- Keep a library of secure code patterns
What you do:
- "Here's how to implement CSRF tokens in our framework"
- "I'll review the authentication flow before you merge"
- "Let me show you how the existing code handles input validation"
3. Code review
Not every PR needs your review. Focus on high-risk areas.
- Authentication and session management
- Authorization and access control
- Data validation and output encoding
- Cryptographic operations
- Configuration changes (especially secrets)
- New dependencies
What you do:
- Add yourself as required reviewer for auth-related paths
- Create a checklist for security-relevant code review
- Review PRs that touch sensitive areas
- Provide feedback that educates, not just blocks
4. Testing
Integrate security into existing test processes.
- Write security test cases
- Configure and maintain SAST/DAST tools
- Review tool findings and triage false positives
- Verify security requirements are tested
What you do:
- "Let's add a test that verifies users can't access other users' data"
- "I'll set up Semgrep to run on every PR"
- "This SAST finding is a false positive — here's why"
5. Deployment
Security doesn't stop when code ships.
- Review deployment configurations
- Verify security headers and TLS
- Check for exposed secrets or debug endpoints
- Monitor for security-relevant errors
What you do:
- "Let's make sure staging has the same security config as production"
- "I'll verify the CSP header is set correctly after deploy"
- "These error logs show authentication failures — let me investigate"
Working with developers
Building trust
Developers have seen security done badly. They expect you to block their work with theoretical concerns. Prove them wrong.
Be helpful, not just critical:
- Don't just say "this is insecure"
- Say "this is vulnerable to X because Y, here's how to fix it"
- Better yet: "here's a PR that fixes it"
Understand constraints:
- Deadlines are real
- Technical debt exists
- Not everything can be fixed immediately
Pick your battles:
- Critical issues: block the release
- Medium issues: fix in next sprint
- Low issues: track for later
Share the why:
- Don't say "because OWASP says so"
- Say "here's what an attacker could do, here's a real example"
Be available:
- Answer questions quickly
- Pair on security implementations
- Don't make people wait for you
Communicating security issues
Bad communication:
"This code is vulnerable to SQL injection. OWASP A03. Fix it."
This tells developers nothing useful. It sounds like you're checking boxes.
Good communication:
"The user input on line 45 goes directly into the SQL query. An attacker could input
'; DROP TABLE users; --and delete the users table. Here's how parameterized queries prevent this. Want me to show you how our ORM handles this safely?"
This explains the risk, shows impact, and offers help.
Security office hours
Set up a regular time when developers can ask security questions:
- 30-60 minutes, same time each week
- Drop-in format — no appointment needed
- Questions can be about current work or general curiosity
- No question is too basic
This creates a low-pressure way to discuss security without formal review processes.
Security champions in each team (scaling up)
In larger organizations, you might train additional Security Champions in each team:
The hub-and-spoke model:
┌──────────┐
│ You │
│ (Lead SC)│
└────┬─────┘
│
┌───────────┼───────────┐
│ │ │
┌───▼───┐ ┌───▼───┐ ┌───▼───┐
│ SC in │ │ SC in │ │ SC in │
│ Team A│ │ Team B│ │ Team C│
└───────┘ └───────┘ └───────┘
Each team has someone who:
- Handles day-to-day security questions
- Does first-pass code reviews
- Escalates complex issues to you
- Attends monthly Security Champion sync
This scales security across multiple teams without hiring dedicated security staff.
Working with DevOps
DevOps controls the pipeline and infrastructure. They're critical partners.
What DevOps cares about
- Reliability: Will this security change break production?
- Speed: Will this slow down deployments?
- Simplicity: Is this another tool to maintain?
- Visibility: Can we see what's happening?
Frame security in these terms.
Common collaboration areas
CI/CD security scanning:
You want security checks in the pipeline. DevOps controls the pipeline.
Your approach:
- Start with non-blocking scans (report only)
- Prove the tool works and false positive rate is low
- Then discuss blocking on critical findings
- Offer to triage findings and reduce noise
Example conversation:
"I'd like to add Trivy to scan our Docker images. It runs in about 30 seconds. Can we add it as a reporting step first? I'll review the findings for a few weeks and then we can decide about blocking on critical CVEs."
Secrets management:
You want secrets out of code. DevOps manages the infrastructure.
Your approach:
- Understand their current secrets handling
- Propose solutions that fit their workflow
- Help with the migration
Example conversation:
"I noticed we have some API keys in environment files. I'm worried about rotation and access control. You already use AWS — what if we moved these to Secrets Manager? I can help update the application code to pull from there instead."
Infrastructure security:
You want secure cloud configuration. DevOps builds and maintains it.
Your approach:
- Don't audit and dump findings on them
- Offer to run security scans together
- Prioritize findings by actual risk
- Help fix, not just find
Example conversation:
"I ran Prowler against our AWS account and found a few things. Most are fine, but there are two S3 buckets that might be too open. Can we look at these together? I want to make sure I understand the intended access pattern."
Building a security-DevOps relationship
Learn their tools:
- Understand the CI/CD pipeline
- Know the infrastructure (AWS/GCP/Azure)
- Learn basic Terraform/Kubernetes
Attend their meetings:
- Incident reviews
- Infrastructure planning
- Tool evaluations
Share useful information:
- New vulnerabilities in tools they use
- Security features in platforms they manage
- Industry incidents relevant to their work
Be the bridge to development:
- Translate developer needs to infrastructure requirements
- Explain why certain configurations matter for application security
Your weekly rhythm
Here's what a Security Champion's development work might look like:
Daily
- Check security tool outputs (SAST, dependency scans)
- Be available for quick questions
- Review security-relevant PRs
- Monitor security-related logs/alerts
Weekly
- Attend 1-2 planning meetings for new features
- Security office hours (30-60 min)
- Review new dependencies added to projects
- Triage any new security findings
Monthly
- Review security requirements coverage
- Update secure coding guidelines
- Security sync with DevOps
- Training session or brown bag lunch
Quarterly
- Full security requirements baseline review
- Update threat models for major features
- Review and update security tooling
- Report security metrics to leadership
Tools you'll use
Development security tools
| Tool | Purpose | When |
|---|---|---|
| Semgrep | SAST (static analysis) | Every PR |
| Snyk | Dependency scanning | Every build |
| Gitleaks | Secrets detection | Every commit |
| Trivy | Container scanning | Every image build |
| OWASP ZAP | DAST (dynamic testing) | Staging deploys |
| Checkov | IaC scanning | Every Terraform change |
Communication and tracking
| Tool | Purpose |
|---|---|
| Slack/Teams channels | Quick questions, alerts |
| Jira/Linear | Tracking security requirements |
| Confluence/Notion | Security guidelines, runbooks |
| GitHub/GitLab | Code review, PR comments |
Your security dashboard
Set up visibility into security status:
## Security Champion Dashboard
### This week
- [ ] PRs reviewed: X
- [ ] Security questions answered: X
- [ ] Planning meetings attended: X
- [ ] Tool findings triaged: X
### Metrics
- Open critical security issues: X
- Average time to resolve critical: X days
- SAST findings this month: X (Y false positives)
- Dependencies with known vulns: X
### Upcoming
- Feature X design review: [Date]
- Security office hours: [Day/Time]
- DevOps security sync: [Date]
Common challenges
"We don't have time for security"
This happens when security is seen as extra work.
Your response:
- Shift security earlier so it's not last-minute work
- Automate what you can (SAST, dependency scans)
- Focus on high-impact, low-effort wins
- Show how security issues found late cost more time
"You're slowing us down"
This happens when security blocks releases.
Your response:
- Make non-critical findings non-blocking
- Be fast in your reviews
- Provide fix suggestions, not just findings
- Reserve blocking for truly critical issues
"That's not a real risk"
This happens when developers dismiss findings.
Your response:
- Show real-world examples of exploitation
- Explain attacker methodology
- Demo the vulnerability if possible
- Accept that you'll be overruled sometimes — document and move on
"We already have a security team"
This happens in companies with dedicated security staff.
Your response:
- You extend their reach, not replace them
- You handle day-to-day, they handle specialized work
- You're the translator between security and development
- They can focus on incident response, pentests, architecture
Measuring your impact
Track these to show value:
Process metrics:
- Security requirements coverage for new features
- Time from security finding to fix
- Percentage of PRs with security review
- Developer participation in security training
Outcome metrics:
- Vulnerabilities found in development vs. production
- Security-related production incidents
- Findings from external pentests (fewer is better)
- Customer security questionnaire response time
Engagement metrics:
- Questions asked in security office hours
- Developers voluntarily adding security tests
- Security being discussed in planning meetings without you
Self-check
Before diving into secure coding practices, verify you understand your role:
Team integration
- You attend feature planning meetings
- Developers know to include you on security-sensitive PRs
- You have access to the codebase and CI/CD
- DevOps knows you and your role
Communication
- Security office hours scheduled
- Slack/Teams channel for security questions
- You've introduced yourself to the development team
- You have regular sync with DevOps
Tooling
- You have access to run security scans
- You can view CI/CD pipeline results
- You have access to security-relevant logs
- Dashboard or tracking for security metrics
Process
- Security requirements tracked somewhere
- PR review process includes security-sensitive paths
- New features get security input during planning
- Security findings have a clear fix workflow
Check off at least 10 of these 12 items before moving to secure coding basics.
What's next
You understand your role in development and DevOps. The next chapters cover the technical skills you need:
- Secure coding basics — the vulnerabilities you'll look for and how to prevent them
- Security requirements management — how to define and track security requirements
- Secrets management — keeping credentials out of code
- CI/CD security — integrating security into the pipeline
- Container and cloud security — securing infrastructure
Let's start with the code itself.