🛡️ Application Security

• Common issues — SQL injection via JDBC string concatenation (fix: PreparedStatement), XXE in XML parsers (fix: disable external entities in DocumentBuilderFactory), deserialization attacks via ObjectInputStream (fix: whitelist classes, use JSON instead), JNDI injection (Log4Shell-style — fix: upgrade, disable lookups)
• SAST tools: Veracode, Checkmarx, SpotBugs with FindSecBugs plugin
• Framework-specific: Spring Security misconfigurations, Struts OGNL injection

• Common issues — SQL injection via string concatenation in ADO.NET (fix: SqlParameter), XSS in Razor views without Html.Encode, insecure deserialization with BinaryFormatter (fix: use System.Text.Json), ViewState tampering (fix: enable MAC validation), path traversal in file operations
• SAST tools: Veracode, SonarQube with C# plugin, Roslyn analyzers, Security Code Scan
• Framework-specific: ASP.NET anti-forgery token missing, insecure authentication cookie settings

• Common issues — SQL injection via f-strings/format in queries (fix: parameterized queries with SQLAlchemy or psycopg2), command injection via os.system/subprocess with shell=True (fix: use subprocess with shell=False and list args), SSTI in Jinja2/Flask (fix: autoescape=True), pickle deserialization RCE (fix: never unpickle untrusted data), SSRF in requests library
• SAST tools: Bandit, Semgrep, Veracode
• Framework-specific: Django CSRF bypass, Flask debug mode in production

• Common issues — prototype pollution, XSS via innerHTML/dangerouslySetInnerHTML (fix: textContent, DOMPurify), npm dependency attacks (typosquatting, supply chain), SSRF in axios/fetch, NoSQL injection in MongoDB queries
• SAST tools: ESLint security plugin, Semgrep, NodeJsScan

• Map all findings to CWE IDs for consistent tracking
• Prioritize by CVSS + reachability (is the vulnerable code path actually triggered?)
• Create language-specific secure coding guidelines and approved library lists

• Embed a security champion in each dev team — a developer who receives extra security training and acts as the first point of contact for security questions
• They review findings before escalation, mentor peers, and advocate for secure design patterns within their squad

• Conduct security-focused code reviews using checklists mapped to OWASP Top 10 and CWE Top 25
• Focus on high-risk areas — authentication flows, authorization checks, input handling, cryptography usage, and data serialization
• Use PR annotations from SAST/SCA tools so developers see findings inline during review

• Publish language-specific secure coding guidelines — approved libraries (e.g., ESAPI for Java, DOMPurify for JS), banned functions (e.g., strcpy, eval, pickle.loads), required patterns (parameterized queries, output encoding)
• Enforce via custom SAST rules and linter configs distributed as shared packages

• When a vulnerability is found — create a Jira ticket with CWE ID, severity, affected code location, attack scenario, and recommended fix with code example
• Schedule a fix-it pairing session for Critical/High findings
• Provide secure code snippets developers can copy-paste
• Set SLAs — Critical: 24-48 hrs, High: 7 days, Medium: 30 days, Low: next sprint

• Quarterly secure coding workshops covering real vulnerabilities found in the codebase (anonymized)
• Lunch-and-learn sessions on new attack vectors
• Gamified CTF events to build security awareness
• Integrate security training into onboarding for new developers

• Track vulnerability recurrence rate — are the same CWE categories showing up repeatedly? Measure MTTR trending down over time
• Monitor developer adoption of security tools (IDE plugins, pre-commit hooks)
• Goal: developers preventing vulnerabilities, not just fixing them

1INJECTION FLAWS (OWASP A03, CWE-89 and CWE-78): How they arise — user input concatenated directly into SQL queries, OS commands, or LDAP queries without sanitization. Exploitation — attacker submits crafted input like OR 1=1-- in login fields to bypass authentication or extract data. Prevention — parameterized queries and prepared statements (never string concatenation), stored procedures, input validation with allowlists, ORM frameworks.

2BROKEN ACCESS CONTROL (OWASP A01, CWE-862 and CWE-639): How they arise — missing authorization checks on API endpoints, IDOR (Insecure Direct Object References) where user IDs are guessable, privilege escalation via role manipulation. Exploitation — change /api/user/123 to /api/user/456 to access another users data, modify hidden form fields or JWT claims to elevate privileges. Prevention — deny by default, enforce server-side authorization on every request, use indirect references (UUIDs), implement RBAC/ABAC, log all access failures.

3CROSS-SITE SCRIPTING (OWASP A03, CWE-79): How they arise — user-supplied data rendered in HTML without encoding. Stored XSS persists in database, Reflected XSS via URL parameters, DOM XSS via client-side JavaScript. Exploitation — inject script tags to steal session tokens via document.cookie. Prevention — context-aware output encoding (HTML, JS, URL, CSS contexts), Content Security Policy headers, DOMPurify for rich text, HttpOnly cookies.

4CRYPTOGRAPHIC FAILURES (OWASP A02, CWE-327 and CWE-328): How they arise — weak algorithms (MD5, SHA1 for passwords), hardcoded keys, missing encryption at rest or in transit. Exploitation — rainbow table attacks on unsalted hashes, MITM on unencrypted channels. Prevention — bcrypt/Argon2 for passwords, AES-256-GCM for data at rest, TLS 1.2+ everywhere, proper key management (HSM/KMS), never roll your own crypto.

5SECURITY MISCONFIGURATION (OWASP A05, CWE-16): How they arise — default credentials left unchanged, unnecessary services enabled, verbose error messages in production, missing security headers. Exploitation — access admin panels with admin/admin, read stack traces to map internal architecture. Prevention — hardening checklists per platform, automated configuration scanning (CIS Benchmarks), infrastructure-as-code with security baselines, remove unused features/frameworks.

• OWASP Top 10 groups vulnerability categories by risk (frequency x impact)
• SANS/CWE Top 25 lists specific weakness types by prevalence in real-world CVEs
• They overlap — e.g., OWASP A03 Injection maps to CWE-89 (SQLi), CWE-78 (OS Command Injection)
• Use OWASP for risk-based prioritization and developer training, use CWE for precise SAST rule mapping and vulnerability classification

• Python is the go-to language for security scripting because of its rich library ecosystem
• Common use cases — writing API integrations to pull scan results from Veracode, Qualys, or Nessus and push them into Jira or ServiceNow automatically
• Building custom parsers to normalize vulnerability data from multiple scanners into a unified format (CSV, JSON, or database)
• Automating compliance evidence collection — scripting checks for CIS Benchmarks, SOC 2 controls, or PCI-DSS requirements and generating audit-ready reports
• Key libraries — requests (API calls), pandas (data analysis and reporting), paramiko (SSH automation), boto3 (AWS security audits), python-nmap (network scanning), BeautifulSoup (web scraping for OSINT)

• Java is used for building enterprise security tools, custom SAST rules, and integrations with Java-based platforms
• Common use cases — writing custom Veracode API wrappers to orchestrate policy scans across hundreds of applications in CI/CD
• Building custom static analysis rules using SpotBugs or Error Prone to detect organization-specific anti-patterns
• Creating security middleware and filters in Spring Boot applications — custom authentication filters, request validation, and audit logging
• Developing custom Burp Suite extensions in Java for automated testing of application-specific vulnerabilities

• Automate the full vulnerability lifecycle — scan scheduling, result ingestion, deduplication, severity enrichment (adding business context to CVSS scores), SLA tracking, and escalation notifications
• Build dashboards that aggregate data from SAST, SCA, DAST, and infrastructure scanners into a single pane of glass
• Script auto-ticketing — when a Critical finding is detected, automatically create a Jira ticket with CWE ID, affected component, remediation guidance, and assign to the right team
• Track metrics programmatically — MTTR, vulnerability density per application, recurrence rates, SLA compliance percentages

• Script compliance checks — verify encryption settings, access controls, logging configurations, and patch levels against policy baselines
• Generate automated compliance reports for auditors — map vulnerabilities to specific control frameworks (NIST 800-53, ISO 27001, PCI-DSS, HIPAA)
• Build drift detection scripts that alert when configurations deviate from approved baselines
• Automate evidence collection for SOC 2 Type II audits — pull access reviews, change management logs, and security scan results into structured reports

• Python script to query Veracode REST API, pull all High/Critical findings across the portfolio, calculate MTTR per team, and email a weekly executive summary
• Java utility to scan all Spring Boot applications for missing security annotations
• Python automation to check AWS S3 bucket policies, IAM configurations, and CloudTrail logging against CIS AWS Benchmark and flag non-compliant resources

• False Positive — the scanner flagged something that is genuinely not a vulnerability
• Example — SAST flags SQL injection but the code uses a parameterized query through an ORM, so injection is impossible
• Mitigated by Design — the vulnerability technically exists in the code path but architectural controls make exploitation impossible
• Example — SAST flags hardcoded credentials in a test file that is excluded from production builds, or DAST finds a reflected XSS but a strict Content Security Policy blocks script execution

• Examine the data flow the tool traced — follow the source (user input) to the sink (dangerous function)
• Verify if input validation, encoding, or parameterization exists along the path that the scanner missed
• Common SAST false positives — ORM-generated queries flagged as SQL injection, encoded output flagged as XSS, dead code paths, test files

• Reproduce the finding manually — send the same payload the scanner used and verify if the vulnerability actually triggers
• Check if a WAF, CSP, or application-level control blocks the attack in practice

• Check if the vulnerable function in the library is actually called by the application (reachability analysis)
• Verify if the vulnerability applies to the deployment context

• Developer submits a mitigation request with evidence — code snippets showing the control, architecture diagrams, or test results proving non-exploitability
• Security engineer reviews the evidence independently — never approve based on developer assertion alone
• Document the decision with rationale, CWE ID, reviewer name, and expiration date
• Set mitigations to expire and require re-review (e.g., every 12 months)

• Track false positive rates per scanner and per application
• Periodically audit approved mitigations — sample 10% quarterly
• Never approve mitigated-by-design for Critical severity findings without a second reviewer

• MME (Mitigate by Mitigation, Mitigate by Environment) — these are Veracode mitigation categories where a finding is accepted because either a code-level mitigation exists that the scanner cannot detect (Mitigate by Mitigation) or network/infrastructure controls prevent exploitation (Mitigate by Environment — e.g., WAF rules, network segmentation, IP whitelisting)
• SbD (Secure by Design) — a formal process where the application architecture is reviewed upfront to confirm security controls are baked into the design rather than bolted on after scanning

• At each SDLC phase, specific security tasks must be completed and approved
• Design Phase — threat model review, security requirements sign-off, data classification
• Development Phase — SAST scan completion, SCA scan with no unapproved Critical/High findings, secure code review
• Testing Phase — DAST scan against staging, penetration testing for high-risk applications
• Pre-Production — all findings remediated or formally mitigated with approved MME requests, policy scan passing at required Veracode Level

• Verify the mitigation type is appropriate — Mitigate by Mitigation requires code evidence (show the sanitization, encoding, or parameterization the scanner missed)
• Mitigate by Environment requires infrastructure evidence (WAF rule screenshots, network diagram showing segmentation)
• Reject if evidence is insufficient
• Critical findings require a second AppSec reviewer plus manager approval

• Validate that the threat model covers all relevant attack vectors
• Confirm security controls are mapped to specific threats
• Review architecture diagrams for secure patterns — defense in depth, least privilege, secure defaults

• Financial regulators (OCC, FFIEC, MAS) require evidence of SDLC security controls
• Maintain separation of duties — the developer cannot approve their own MME request
• Track aging mitigations with expiration dates

MME submitted without evidence, Mitigate by Environment claimed without infrastructure controls, SCA finding mitigated when a patch is available — reject and require the upgrade.

1NIST 800-53 AND NIST CSF: NIST SP 800-53 provides a catalog of 1,000+ security and privacy controls organized into 20 families. NIST CSF organizes security into 5 functions — Identify, Protect, Detect, Respond, Recover. Map SAST/DAST/SCA scanning to SI-2 (Flaw Remediation), SA-11 (Developer Testing), RA-5 (Vulnerability Monitoring).

• 12 requirements for cardholder data
• Requirement 6 — develop and maintain secure systems (6.2 risk ranking, 6.3 secure SDLC, 6.5 common vulnerabilities, 6.6 WAF or pen test)
• Requirement 11 — quarterly ASV scans

Financial institution IT security guidelines — risk assessments, secure coding, independent testing, vendor management.

Section 404 requires internal controls over financial reporting — access controls, segregation of duties, change management with approval workflows, audit trails.

• Hardening benchmarks for OS, databases, cloud
• CIS Control 16 covers AppSec scanning, secure coding training, remediation SLAs
• Automate with CIS-CAT or AWS Config Rules

• Map controls across frameworks to avoid duplicate work
• Use GRC platforms (Archer, ServiceNow GRC) for evidence tracking
• Maintain a compliance calendar — quarterly ASV scans, annual pen tests, SOX testing cycles

1WHY IaC FOR SECURITY TOOLS: Manual deployment leads to configuration drift and inconsistent coverage. IaC is declarative, version-controlled, peer-reviewed, and automatically deployed.

• WAF — Terraform modules for AWS WAF, Azure Front Door
• SIEM — Splunk forwarders, Elastic Security agents via Terraform/Ansible
• EDR — CrowdStrike Falcon via Ansible playbooks
• CSPM — Prisma Cloud, AWS SecurityHub via Terraform
• Secrets Management — HashiCorp Vault clusters via Terraform

• Reusable modules per tool
• Workspaces or Terragrunt for identical stacks across environments
• Remote state backends with encryption

• OPA with Rego policies, Checkov/tfsec to scan Terraform plans
• Block terraform apply on failures

• Security team writes Terraform modules, submits PRs
• Pipeline — plan, policy validation, approval gate, apply
• Blue-green deployments for zero-gap coverage

• Scheduled terraform plan to detect manual changes
• Auto-remediate drift
• Full Git audit trail for compliance