Security used to be a gate at the end of the pipeline. Developers shipped code, and security did a final scan before deployment. That model is dead.

Modern software moves too fast. By the time you find a vulnerability at the end, it’s already embedded in ten other services, three environments, and a production database. The solution is simple in theory but hard in practice — move security everywhere.

That’s where Shift Left and Shift Right come in.

What is Shift Left Security?

Shift Left means integrating security at the earliest stages of development — during planning, coding, and testing — rather than treating it as a final checkpoint.

The core idea: find vulnerabilities when they are cheapest to fix. A bug caught in the IDE costs almost nothing. The same bug caught in production can cost thousands of dollars, days of downtime, and your company’s reputation.

Prevention is cheaper than remediation. Always.

What Shift Left Focuses On

• Proactive identification of bugs, vulnerabilities, and misconfigurations
• Security embedded in the developer’s workflow — not bolted on later
• Automated gates that block bad code before it ever ships

Shift Left Tools & Methods

Shift Left in Practice

# Step 1 — Install pre-commit framework
pip install pre-commit

# Step 2 — Create .pre-commit-config.yaml in your repo root
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.0
    hooks:
      - id: gitleaks

  - repo: https://github.com/semgrep/semgrep-pre-commit
    rev: v1.152.0
    hooks:
      - id: semgrep

# Step 3 — Activate hooks in your local .git/ directory
pre-commit install

# Step 4 — Test against all files (optional but recommended)
pre-commit run --all-files

# Keep hooks up to date automatically
pre-commit autoupdate

# Skip checks when needed (use sparingly)
SKIP=gitleaks,semgrep git commit -m "your message"

Add this to your .github/workflows/security.yml:

# Option 1 — Container-based projects (scan Docker image)
- name: Trivy image scan
  uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1 # v0.35.0
  with:
    scan-type: 'image'
    image-ref: 'myapp:latest'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'

# Option 2 — Non-container projects (scan source code + dependencies)
- name: Trivy filesystem scan
  uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1 # v0.35.0
  with:
    scan-type: 'fs'
    scan-ref: '.'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'

Not using containers? Use scan-type: 'fs' — Trivy scans your source code and application dependencies (npm, pip, Maven, Go modules) directly. No Docker required.

Benefits of Shift Left

• Lower remediation costs — fix at code, not in production
• Faster development cycles — security becomes part of the workflow, not a blocker
• Higher quality code — developers build security intuition over time
• Compliance — automated evidence collection for SOC 2, ISO 27001

What is Shift Right Security?

Shift Right extends security into the operational, post-deployment phase. It acknowledges a hard truth: no matter how well you shift left, threats will still emerge in production.

Zero-day exploits don’t care about your SAST scans. Behavioral anomalies don’t show up in pre-commit hooks. Configuration drift happens silently. You need eyes on production — always.

Assume breach. Detect fast. Respond faster.

What Shift Right Focuses On

• Protecting live applications from zero-day exploits and behavioral anomalies
• Real-time monitoring of what’s actually happening in your environment
• Incident response — detecting and containing threats before they escalate

Shift Right Tools & Methods

Shift Right in Practice

To detect brute force and privilege escalation, add these custom correlation rules to /var/ossec/etc/rules/local_rules.xml on your Wazuh manager:

<!-- Place in /var/ossec/etc/rules/local_rules.xml -->

<!-- SSH Brute-Force: 6+ failed logins from same IP in 120 seconds -->
<group name="syslog,sshd,">
  <rule id="100001" level="10" frequency="6" timeframe="120">
    <if_matched_sid>5710</if_matched_sid>
    <same_source_ip />
    <description>Possible SSH brute-force: 6+ failed logins from same IP in 120s</description>
  </rule>
</group>

<!-- Windows Brute-Force: 5 failed logons (Event ID 4625) in 60 seconds -->
<group name="windows,authentication_failed,">
  <rule id="100002" level="10" frequency="5" timeframe="60">
    <if_matched_sid>60112</if_matched_sid>
    <same_source_ip />
    <description>Possible Windows brute-force: 5+ failed logons from same IP in 60s</description>
  </rule>
</group>

<!-- Linux Privilege Escalation — sudo/su monitoring -->
<!-- Rule 5710 = sudo usage, 5716 = su usage (built-in Wazuh) -->
<!-- Add custom correlation rule below -->
<group name="syslog,sudo,">
  <rule id="100003" level="12">
    <if_sid>5710</if_sid>
    <description>Privilege escalation via sudo detected (Linux)</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>
</group>

<!-- Suspicious Python execution — possible priv esc via script -->
<group name="syscheck,">
  <rule id="100004" level="12">
    <if_sid>505</if_sid>
    <field name="file">/usr/bin/python3</field>
    <description>Suspicious Python script executed — possible privilege escalation</description>
    <mitre>
      <id>T1068</id>
    </mitre>
  </rule>
</group>

<!-- Windows privilege escalation via token manipulation -->
<!-- Rule 60107 = built-in Wazuh Windows Event log detection -->

# /etc/audit/audit.rules — track privilege escalation attempts
# Logs any process where euid becomes 0 (root) but real uid differs
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k priv_esc

Note: Restart wazuh-manager after adding custom rules: systemctl restart wazuh-manager

Benefits of Shift Right

• Immediate threat detection in real-world conditions
• Real user data — surfaces issues that simulated tests miss
• Runtime resilience — your system stays protected even after deployment
• Continuous feedback loop — production findings feed back into development

Shift Left vs Shift Right — Key Differences

The SDLC Security Pipeline

The “Shift Everywhere” Strategy

Neither approach alone is enough. Here is how I think about combining them:

My Recommended Minimum Pipeline

Pre-commit   →  Gitleaks + Semgrep  (stop secrets and bad code at source)
CI/CD        →  Trivy + OWASP DC    (block on critical CVEs before build)
IaC          →  Checkov             (catch misconfigs before they reach cloud)
Test/Stage   →  Burp Suite / ZAP    (DAST — run manually or scheduled, not on every commit)
Runtime      →  Wazuh               (detect threats that slip through)

Why Trivy AND OWASP Dependency Check? They are not redundant — they complement each other. Trivy scans container images and OS packages (Alpine, Ubuntu, etc.), while OWASP DC scans application-level dependencies (npm, Maven, pip, NuGet). Running both gives you full coverage across the entire dependency tree.

What About IAST?

IAST (Interactive Application Security Testing) sits between SAST and DAST — an agent runs inside your application during functional testing. Because it has internal visibility it produces far fewer false positives than DAST and catches runtime issues that SAST misses. The tradeoff: it requires an agent installed in your app and works best with automated functional test suites. If you have the setup, IAST gives you the best of both worlds.

Note on DAST: Avoid running DAST on every commit — it is slow, resource-heavy, and produces false positives that cause alert fatigue. Instead run it on a schedule (nightly or weekly) against staging, or manually before major releases. Tune your rules before trusting the results.

When DAST isn’t enough — consider Penetration Testing. DAST automates known attack patterns but misses business logic flaws, chained vulnerabilities, and creative attack paths. A skilled penetration tester thinks like a real attacker — testing what automated tools never will. Run a manual pentest at least once a year, or before any major release. DAST finds the obvious; pentesters find the unexpected.

Priority Order — Where to Start

Week 1 — Add pre-commit hooks. Stop secrets leaking. This single step prevents 40% of common breaches.

Month 1 — Add Trivy to CI/CD. Block deployments on CRITICAL CVEs. Automated, zero manual effort after setup.

Quarter 1 — Deploy Wazuh SIEM. Correlate logs across your stack. Build detection rules around OWASP Top 10.

Year 1 — Full shift everywhere coverage. Chaos engineering. Incident runbooks. Security as team culture.

Common Mistakes to Avoid

• Scanning but not blocking — if a critical CVE doesn’t fail your build, the scan is just decoration
• Alert fatigue — one well-tuned SIEM beats five noisy ones. Tune ruthlessly
• Skipping IaC scanning — most cloud breaches start from misconfigured infrastructure, not app code
• No runbooks — detection without a response plan is useless. Write runbooks before you need them
• Treating shift left as “only for developers” — security engineers need to own the pipeline gates too

Final Thought

Shift left to prevent. Shift right to survive. Do both to win.

Security is not a checkbox. It is a culture that lives in every commit, every pipeline gate, and every production alert. The goal is not to find the perfect tool — it is to build a system where vulnerabilities have nowhere to hide.

Start small. Automate ruthlessly. Tune continuously.