Executive Overview

Application Security Analysts are responsible for preventing vulnerabilities before they reach production, not simply detecting attacks after the fact.

This project demonstrates a shift-left application security pipeline that transforms attacker detection logic into automated security tests executed during the software development lifecycle (SDLC).

Instead of monitoring logs for SQL injection or XSS attempts after deployment, the system actively injects attack payloads into the application during the build phase, failing the build if defenses are inadequate.

The project is intentionally designed to mirror enterprise AppSec workflows used in financial environments where vulnerabilities can directly translate into fraud, data integrity loss, or market disruption.

Analyst discovering insights
How Might We

How might we enable developers to validate real, exploitable security issues early in the SDLC without slowing delivery or increasing cognitive load?

Problem Statement

Traditional security monitoring is reactive by design—and that breaks down in high-stakes financial environments.

What traditional monitoring focuses on

  • Detecting malicious input in logs
  • Alerting after an attack attempt
  • Responding reactively

In high-stakes financial environments, this approach is insufficient.

What the real objective is

  • Validate defenses before deployment
  • Ensure vulnerabilities never reach production
  • Embed security directly into the SDLC

The goal is prevention: catch exploitable behavior before code ships.



Alex Morgan, Senior Backend Developer

Alex Morgan is a senior backend developer working on production-critical systems where security issues can directly impact customers and revenue.

She values security feedback that arrives early in CI/CD, avoids false positives, and clearly explains what needs to be fixed—without slowing delivery or introducing unnecessary rework.

Alex Morgan

Sr Backend Developer

Primary user persona for AppSec CI Gate Financial technology context

Goals

  • Ship code securely without impeding delivery.
  • Avoid production security incidents.
  • Receive actionable security feedback early.

Needs

  • Tests in CI/CD for early security feedback.
  • Clear, actionable pass/fail signals.
  • Simple remediation guidance.

Pain Points

  • Late-arriving security findings cause rework.
  • Noisy scanners with unclear results.
  • False positives erode trust in security tools.

Security feedback should protect delivery, not slow it down.

Architecture Overview

Design Goal: Shift Left Application Security


The primary design goal was to move meaningful application security validation earlier in the software development lifecycle—before code reaches production—while remaining compatible with real developer workflows.

Rather than producing exhaustive vulnerability reports, the system was designed to help developers quickly determine whether a change introduced real, exploitable risk that should block release

To support this shift-left approach, the system prioritizes:

  • Early feedback aligned with CI/CD principles
  • Clear pass/fail outcomes instead of ambiguous alerts
  • Actionable remediation guidance developers can apply immediately

This goal informed all architectural, technical, and presentation decisions.


Security Objectives

The system demonstrates four core AppSec capabilities aligned to the persona’s goals and needs:

  • Identifies common OWASP Top 10 vulnerabilities
  • Demonstrates how scanners actually work (not just running tools)
  • Produces actionable security findings suitable for dev teams
  • Shows judgment: what’s real, what’s noise, what’s exploitable

Core Design Principles

Shift Left
Test security controls during development, not after release.
Automation First
Security checks must run consistently and automatically.
Language Agnostic
Secure the pipeline, not just one programming language.
Developer Friendly
Findings must be actionable and non-adversarial.
Evidence Driven
All failures include reproducible proof.

Threat Model (High Level)

Threats Considered

  • SQL Injection against financial account workflows
  • Reflected XSS in user-controlled inputs
  • Weak output encoding
  • Missing defensive HTTP headers
  • Account takeover precursors

Impact in Financial Context

  • Unauthorized access to trading accounts
  • Data integrity violations
  • Fraud and regulatory exposure
  • Loss of trust in market systems

System Architecture

The system is designed as a CI-integrated security pipeline that actively tests web application behavior during development and produces enforceable security decisions before deployment.

Rather than operating as a standalone scanner or post-deployment monitor, security validation is embedded directly into the delivery workflow.

  1. Developer Commit
  2. CI Pipeline Trigger
  3. Security Test Harness (Python)
  4. Active Payload Injection
  5. Response Analysis & Triage
  6. PASS → Deploy
  7. FAIL → Block Build

Architecture Execution Flow

When a developer commits code, the CI pipeline automatically triggers a Python-based security test harness (sort of like an automated security check that that attempts common attacks) that executes against designated web application endpoints.

The harness performs active payload injection, simulating common web attack techniques such as SQL injection and reflected input manipulation. Application responses are analyzed for behavioral changes that indicate exploitability, rather than relying on static indicators alone.

Based on this analysis, the system produces a binary, enforceable decision:

  • PASS — No exploitable behavior detected; deployment proceeds.
  • FAIL — Exploitable behavior confirmed; the build is blocked.

All failed decisions include reproducible evidence and remediation context, ensuring that security enforcement is transparent, defensible, and actionable for developers.

Web Scanner: Technical Implementation

The web scanner functions as a security test harness—a set of security-focused unit tests that actively validate exploitability, rather than a passive scanner that only reports findings.

Step 1

Convert Detection Logic into Security Tests

  • Actively inject SQLi payloads into target endpoints.
  • Evaluate responses for exploitability signals:
SQL error leakage
Database errors or stack traces revealed in the response.
Boolean logic manipulation
Response changes when injected logic alters query behavior.
Response length anomalies
Significant content shifts compared to a safe baseline request.
Step 2

XSS Defense Validation

  • Inject reflected XSS payloads into user-controlled inputs.
  • Inspect response bodies for payload reflection.
  • Fail the build if unencoded input is rendered back to the user.
Step 3

HTTP Security Header Enforcement

Validate baseline defensive posture by checking for required headers:

  • Content-Security-Policy
  • X-Frame-Options
  • X-Content-Type-Options
  • Referrer-Policy
Step 4

CI/CD Gate Behavior

  • All tests run automatically during CI.
  • Any confirmed vulnerability blocks deployment (non-zero exit).
  • Security failures are treated like failing unit tests (same enforcement path).
Enforcement rule
If exploitability is confirmed, the pipeline returns FAIL and blocks release until remediation passes the same tests.
Step 5

Enterprise Tool Orchestration (Language-Agnostic)

  • Python orchestrates enterprise SAST/DAST tools.
  • Normalizes results into a consistent finding format.
  • Filters common false positives before surfacing issues to developers.
Step 6

Analyst Triage & False Positive Reduction

  • Findings must meet multiple exploitability indicators to be enforced.
  • Results are classified for clarity and workflow:
  • Confirmed
  • Needs Manual Review
  • False Positive
Step 7

Developer Education & Advocacy

  • Visual request/response flow diagrams for fast understanding.
  • Annotated payload examples with reproduction steps.
  • Plain-language explanations of impact and fix.
Design intent
Findings are written as engineering feedback—actionable, non-adversarial, and easy to verify.

Financial Domain Alignment

This project explicitly frames threats in financial terms and reflects an exchange-grade security mindset.

  • Account takeover risk
  • Transaction integrity risk
  • Session hijacking & fraud exposure
  • Cryptographic trust in market systems

The pipeline reflects the mindset required in exchange-grade security environments: stop exploit paths early, attach proof, and keep developer delivery moving.

Results & Impact

What the pipeline changes in practice.

Earlier Detection

Vulnerabilities are identified before deployment.

Actionable Feedback

Developers receive immediate, usable remediation guidance.

Repeatable Testing

Security tests become repeatable and measurable.

Security by Design

The SDLC enforces security as a release requirement.

Key Takeaways

What matters most.

  1. 1 Application Security is an engineering discipline, not monitoring.
  2. 2 Prevention is more valuable than detection.
  3. 3 Automation enables consistency at enterprise scale.
  4. 4 Clear communication is a security control.

Resume-Ready Highlights

Role-aligned highlights.

  • Built a shift-left application security pipeline enforcing security during the SDLC.
  • Developed automated security unit tests for SQL injection and XSS defenses.
  • Orchestrated SAST/DAST tooling across polyglot codebases using Python.
  • Reduced false positives through analyst triage logic.
  • Delivered developer-friendly security findings with visual explanations.

Closing Statement

This project represents the transition from log watcher to pipeline builder. It demonstrates how application security analysts prevent breaches by embedding security directly into the development lifecycle— aligning with the expectations of enterprise and financial security teams.

OWASP Top 10 Secure SDLC SQL Injection Pre-Authentication