ISO 27001 A.8.29: Security Testing in Development and Acceptance

Quick Reference (60 Seconds)

Control: A.8.29, Security Testing in Development and Acceptance
Purpose: Ensure applications are tested for security vulnerabilities during development and before acceptance into production, catching flaws before they reach live environments.
Who it applies to: All organizations that develop, acquire, or customize software applications.
Minimum viable actions:

• Define security testing requirements for all applications before acceptance
• Implement SAST in CI/CD for automated code security scanning
• Conduct DAST on staging/pre-production environments
• Perform manual security testing (penetration testing) for critical applications before go-live
• Establish security acceptance criteria that must be met before deployment approval

Key deliverables: Security Test Plan, Security Test Report, Acceptance Criteria Checklist, Vulnerability Remediation Tracker, Security Sign-off Document.

Audit questions you should be able to answer:

• What security testing is performed before applications go live?
• Who approves security testing results?
• Can you show me the security test report for [application name]?
• What happens if security testing finds critical vulnerabilities before go-live?

What the Standard Actually Requires

Figure · Process

What A.8.29 asks you to do

Annex A 8.29 asks organizations to define and carry out security testing during the development and acceptance process.

This control is about validation, ensuring that security requirements have been implemented correctly and that the application is free from known vulnerabilities before it is accepted into production. The standard expects organizations to:

1. Define security testing requirements, What testing must be performed, when, and by whom
2. Implement security testing in the SDLC, Testing is not a one-time event but integrated throughout development
3. Test during development, Unit testing, integration testing, and code-level security testing
4. Test during acceptance, System testing, penetration testing, and user acceptance testing with security focus
5. Define acceptance criteria, Clear security thresholds that must be met before deployment
6. Document and track findings, Vulnerabilities must be tracked to remediation
7. Obtain security sign-off, Independent security approval before production deployment

What the Standard Does NOT Require

• The standard does not mandate a specific testing methodology (black box, white box, gray box)
• It does not require 100% vulnerability-free code (impossible), but rather systematic testing and acceptable risk
• It does not specify particular tools, but requires that testing be performed and documented
• It does not require manual penetration testing for every minor change, but rather risk-based testing

Why Security Testing in Development and Acceptance Matters

The impact of Late Discovery

When security testing is skipped or deferred:

• Vulnerabilities reach production where they are exploitable by attackers
• Remediation becomes exponentially more premium-tier due to production constraints, downtime, and rollback complexity
• Customer trust erodes when security flaws are discovered by customers or attackers rather than internal testing
• Compliance failures occur when auditors discover untested applications in production
• Incident response overhead skyrocket because vulnerabilities are unknown and unpatched

The Shift-Left Imperative

"Shift-left" security testing moves testing earlier in the development lifecycle:

Security testing in development and acceptance is the last line of defense before vulnerabilities reach production. It is where the organization's investment in secure requirements, architecture, and coding is validated.

The Indian Context

Indian organizations face unique security testing challenges:

• Rapid digital transformation: UPI processing 10+ billion transactions monthly requires rigorous testing of payment applications
• Fintech compliance: RBI mandates security testing for payment systems and banking applications
• DPDP Act 2023: Organizations must demonstrate security testing for personal data processing systems
• Startup ecosystem: Limited security budgets mean testing must be efficient and automated
• Outsourced development: Offshore teams may not perform adequate security testing; acceptance testing becomes critical
• AI/ML adoption: New attack surfaces (adversarial examples, model extraction) require specialized testing
• Government Digital India: Citizen-facing applications must be bulletproof; security testing is mandatory for government projects

Scope and Applicability

In Scope

This control applies to:

• All new applications, In-house developed, outsourced, or COTS with customizations
• Major enhancements, New modules, significant feature additions, architecture changes
• Integration projects, APIs, middleware, third-party connectors
• Cloud-native applications, Serverless, containerized, microservices
• Mobile applications, iOS, Android, cross-platform
• AI/ML applications, Models, inference pipelines, training systems
• Infrastructure as Code, Terraform, CloudFormation, Kubernetes manifests
• Database changes, Stored procedures, schema changes, data migration scripts
• Security patch validation, Testing that patches don't introduce new vulnerabilities

Out of Scope (with caveats)

• Minor bug fixes, Patches that don't change security architecture (but security regression testing is recommended)
• Cosmetic changes, UI updates with no security impact
• Configuration-only changes, Settings adjustments (covered by A.8.9)
• Emergency patches, Critical security patches may have expedited testing, but must be tested

Caveat: Even minor changes can introduce security regressions. Automated regression testing should catch these, but manual review of change impact is recommended.

Applicability by Organization Type

Key Definitions and Terminology

Relationship to Other Controls

Directly Related Controls

Framework Mapping

Implementation Roadmap (Week-by-Week)

Phase 1: Foundation (Weeks 1–3)

Week 1: Policy and Scope Definition

• Draft the Security Testing Policy
• Define testing scope (what applications, what types of testing)
• Define testing triggers (new app, major change, periodic, emergency patch)
• Establish risk-based testing tiers

Week 2: Test Strategy and Tool Selection

• Select SAST, DAST, SCA tools for automated testing
• Define manual testing approach (penetration testing, red teaming)
• Create the Security Test Plan template
• Define acceptance criteria and security sign-off process

Week 3: Baseline and Environment Setup

• Establish testing environments (staging, pre-production)
• Run baseline SAST/DAST on existing applications
• Create vulnerability inventory
• Set up testing tools and integrate with CI/CD

Deliverables: Security Testing Policy, Test Strategy, Tool Selection, Baseline Report, Test Environment

Phase 2: Pilot (Weeks 4–6)

Week 4-5: Pilot Application Testing

• Select one critical application for pilot security testing
• Conduct full security testing: SAST, DAST, SCA, manual penetration test
• Document findings and create remediation plan
• Validate acceptance criteria process

Week 6: Process Refinement

• Refine test plan template based on pilot findings
• Update acceptance criteria thresholds
• Improve vulnerability triage process
• Train testers on tools and methodology

Deliverables: Pilot Test Report, Remediation Plan, Updated Templates, Trained Testers

Phase 3: Rollout (Weeks 7–12)

Week 7-9: Organization-Wide Deployment

• Apply security testing to all new applications and major changes
• Integrate SAST/SCA into all CI/CD pipelines
• Establish DAST scheduling for all staging environments
• Implement security acceptance gates

Week 10-12: Manual Testing Program

• Establish penetration testing schedule (quarterly for critical, annually for high)
• Engage external penetration testers for independent validation
• Implement red team exercises for critical applications
• Create vulnerability remediation workflow

Deliverables: Organization-wide testing, CI/CD integration, Penetration Testing Schedule, Remediation Workflow

Phase 4: Optimization (Weeks 13–16)

Week 13-14: Metrics and Monitoring

• Define and collect KPIs (see Section 13)
• Conduct first internal audit of testing process
• Identify gaps and improvement opportunities

Week 15-16: Continuous Improvement

• Implement automated regression testing
• Add fuzzing and advanced testing for critical apps
• Integrate threat intelligence into testing (new CVEs trigger new tests)
• Update testing methodology with emerging techniques

Deliverables: KPI Dashboard, Internal Audit Report, Automated Regression, Updated Methodology

Maturity Model

Detailed Implementation Guidance

Security Testing Lifecycle

The security testing lifecycle follows these phases:

Plan Tests → Prepare Environment → Execute Tests → Analyze Results → 
Report Findings → Remediate Vulnerabilities → Re-test → Sign Off → Deploy

Phase 1: Plan Security Tests

For every application or major change, define:

Testing Scope:

• What components will be tested (frontend, backend, API, database, infrastructure)
• What types of testing will be performed (SAST, DAST, SCA, manual, fuzzing)
• What will NOT be tested (scope exclusions)

Testing Triggers:

• New application: Full testing suite (SAST + DAST + SCA + penetration test)
• Major enhancement: SAST + DAST + targeted manual testing for changed components
• Minor change: SAST + automated regression testing
• Emergency patch: Smoke testing + targeted SAST for patch area
• Periodic: Full DAST + penetration test (quarterly/annually)

Risk-Based Testing Tiers:

Phase 2: Prepare Testing Environment

Environment Requirements:

• Testing environment must mirror production (same OS, same versions, same configurations)
• Test data must be representative but not production data (see A.8.33)
• Testing environment must be isolated from production
• Test environment must have appropriate monitoring and logging
• Access to testing environment must be controlled (testers only)

Test Data Preparation:

• Use synthetic data that covers edge cases, boundary conditions, and attack patterns
• Include known malicious inputs for injection and XSS testing
• Include oversized inputs for buffer overflow and DoS testing
• Include encoded/escaped inputs for filter evasion testing

Tool Configuration:

• SAST rules tuned for the technology stack
• DAST scan configured with authentication credentials
• SCA configured with the organization's vulnerability thresholds
• Penetration testing tools updated to latest versions

Phase 3: Execute Security Tests

Automated Testing (CI/CD):

Developer Commit → Build → Unit Tests → SAST → SCA → Integration Tests → 
Deploy to Staging → DAST → Security Smoke Test → Report Findings

SAST Execution:

• Run on every commit/merge request
• Scan all source files in the application
• Scan infrastructure as code (Terraform, CloudFormation, Kubernetes YAML)
• Generate SARIF output for integration with GitHub/GitLab security dashboards
• Block build on critical/high findings (configurable threshold)

DAST Execution:

• Run on staging environment after deployment
• Authenticated scanning (with test credentials for all user roles)
• Crawl all application paths and API endpoints
• Test for OWASP Top 10 vulnerabilities
• Generate report with exploitability assessment

SCA Execution:

• Run on every build
• Scan all dependency files (package.json, requirements.txt, pom.xml, etc.)
• Check against vulnerability databases (NVD, OSV, GitHub Advisory Database)
• Block build on critical CVEs above threshold
• Generate SBoM for compliance

Manual Testing:

• Penetration Testing: Simulated attack by certified ethical hackers
• Business Logic Testing: Testing for flaws that automated tools cannot find (race conditions, workflow bypasses, privilege escalation)
• API Testing: Specialized testing for REST, GraphQL, SOAP APIs
• Mobile Testing: Testing for mobile-specific vulnerabilities (insecure storage, certificate pinning, code obfuscation)
• Social Engineering Testing: Testing human vulnerabilities (phishing, pretexting) as part of red team exercises

Fuzzing:

• Input fuzzing for API endpoints, file uploads, and form fields
• Protocol fuzzing for network services
• Format fuzzing for file parsers (PDF, XML, JSON, images)
• Memory fuzzing for C/C++ applications (AFL, libFuzzer)

Phase 4: Analyze Results

Vulnerability Triage:

1. Validate findings, Confirm that automated findings are real (not false positives)
2. Assess severity, Use CVSS v3.1 or custom scoring based on exploitability, impact, and likelihood
3. Assess business impact, Consider data sensitivity, regulatory requirements, and business criticality
4. Prioritize for remediation, Critical and high findings first, then medium, then low

Severity Classification:

False Positive Management:

• Document false positives with justification
• Suppress in tool with documented reason
• Review suppression decisions quarterly
• Track false positive rate as a KPI

Phase 5: Report Findings

Security Test Report Contents:

• Executive summary (risk score, critical findings count, go/no-go recommendation)
• Testing scope and methodology
• Findings detailed report (vulnerability description, severity, evidence, impact, remediation)
• Vulnerability matrix (all findings with severity and status)
• Remediation guidance (specific, actionable steps with code examples where applicable)
• Risk acceptance documentation (for findings that will not be fixed)
• Re-testing results (for remediated findings)
• Security sign-off (or conditions for sign-off)

Phase 6: Remediate Vulnerabilities

Remediation Workflow:

1. Vulnerability assigned to development team
2. Developer fixes the vulnerability
3. Fix verified by peer review
4. Re-test to confirm fix (automated or manual)
5. Vulnerability closed in tracking system
6. Metrics updated

Risk Acceptance:

• If a vulnerability cannot be fixed within timeline, risk acceptance is required
• Risk acceptance requires documented justification, compensating controls, and approver
• Critical vulnerabilities require CISO approval for risk acceptance
• Risk acceptance is reviewed quarterly

Phase 7: Re-test

• All remediated critical/high vulnerabilities must be re-tested
• Re-testing can be automated (SAST/DAST) or manual (penetration test)
• Re-test confirms the fix works and doesn't introduce new vulnerabilities
• Re-test results are documented in the final report

Phase 8: Security Sign-off and Deployment

Security Sign-off Criteria:

• All critical vulnerabilities are remediated or risk-accepted with CISO approval
• All high vulnerabilities are remediated or risk-accepted with security lead approval
• Medium and low vulnerabilities are tracked for future remediation
• Security test report is complete and approved
• Acceptance criteria are met

Go/No-Go Decision:

• Go: Security sign-off obtained, application approved for deployment
• No-Go: Critical vulnerabilities remain unaddressed, deployment delayed until fixed
• Go with Conditions: Deployment approved with monitoring, compensating controls, or accelerated remediation timeline

Types of Security Testing

Static Application Security Testing (SAST)

When: During development, on every commit/merge request
What: Source code analysis for vulnerability patterns
Strengths: Finds code-level issues early, integrates into CI/CD, covers all code paths
Weaknesses: High false positive rate, cannot find runtime issues, cannot test business logic
Best Practices:

• Tune rules for your technology stack
• Suppress false positives with documented justification
• Use high-confidence rules for build blocking
• Train developers to interpret and fix SAST findings
• Track SAST coverage (percentage of code scanned)

Dynamic Application Security Testing (DAST)

When: On staging/pre-production environment, after deployment
What: Runtime testing by simulating attacks against running application
Strengths: Finds runtime issues, tests actual deployed configuration, low false positives
Weaknesses: Cannot find code-level issues, limited coverage of application paths, requires running environment
Best Practices:

• Use authenticated scanning for full coverage
• Configure scan to cover all user roles and API endpoints
• Run DAST after every deployment to staging
• Integrate DAST results into vulnerability tracking system
• Use DAST to validate SAST findings (are they actually exploitable?)

Software Composition Analysis (SCA)

When: During build, on every dependency change
What: Analysis of third-party libraries and frameworks for known vulnerabilities
Strengths: Finds known CVEs, easy to automate, low false positives
Weaknesses: Only finds known vulnerabilities, cannot find custom code issues, license compliance focus
Best Practices:

• Integrate into CI/CD pipeline
• Block builds on critical CVEs
• Use automated dependency updates (Dependabot, Renovate)
• Generate SBoM for compliance and audit
• Monitor for new CVEs affecting your dependencies

Interactive Application Security Testing (IAST)

When: During functional testing, in testing environment
What: Instrumented testing that combines SAST and DAST by monitoring application during runtime
Strengths: High accuracy, low false positives, finds both code and runtime issues, integrates with functional testing
Weaknesses: Requires application instrumentation, may impact performance, requires running application
Best Practices:

• Integrate with QA functional testing
• Use for critical applications where accuracy is paramount
• Combine with SAST and DAST for complete coverage
• Monitor performance impact during testing

Manual Penetration Testing

When: Before acceptance for critical/high-risk applications, quarterly/annually for ongoing applications
What: Simulated cyberattack by certified ethical hackers
Strengths: Finds business logic flaws, validates real-world exploitability, tests human factors, provides context
Weaknesses: premium-tier, time-consuming, point-in-time, cannot test all paths
Best Practices:

• Use certified testers (certified, GPEN, GWAPT)
• Define scope clearly (in-scope/out-of-scope)
• Include both black box (no knowledge) and white box (full knowledge) testing
• Test for business logic vulnerabilities (automated tools cannot find these)
• Include social engineering if scope allows
• Conduct re-test after remediation
• Obtain independent testing for compliance (PCI DSS, RBI)

API Security Testing

When: For every API release, after deployment to staging
What: Specialized testing for REST, GraphQL, SOAP, and gRPC APIs
Focus Areas:

• Authentication and authorization (JWT, OAuth, API keys, mTLS)
• Input validation (JSON schema validation, content-type enforcement)
• Rate limiting and throttling bypass
• Mass assignment, injection, and deserialization
• Business logic flaws (BOLA, Broken Object Level Authorization)
• Error handling and information disclosure Tools: OWASP ZAP, Postman + security tests, Burp Suite, RESTler, Nuclei

Mobile Security Testing

When: For every mobile app release, before app store submission
What: Specialized testing for iOS and Android applications
Focus Areas:

• Local storage security (keychain, shared preferences, SQLite)
• Network security (certificate pinning, TLS, intercepting proxy)
• Code obfuscation and anti-tampering
• Biometric authentication implementation
• Deep linking and intent handling
• Clipboard and keyboard security
• Screenshot and screen recording protection Tools: MobSF, Frida, Objection, Burp Suite Mobile Assistant, QARK

AI/ML Security Testing

When: For every AI/ML model release, before deployment to production
What: Specialized testing for AI/ML applications
Focus Areas:

• Adversarial strength (evasion attacks, poisoning attacks)
• Model extraction and inversion attacks
• Prompt injection (for LLMs)
• Data leakage in training data
• Bias and fairness testing
• Model drift and performance degradation
• RAG/Vector DB security (retrieval filtering, access control) Tools: Foolbox, ART (Adversarial Strength Toolbox), CleverHans, TextAttack, Giskard

Fuzzing

When: For critical input handlers, file parsers, and API endpoints
What: Automated testing with random, malformed, or unexpected inputs
Types:

• Black-box fuzzing: No knowledge of internal structure
• White-box fuzzing: Knowledge of code structure (coverage-guided)
• Mutation-based fuzzing: Mutates existing valid inputs
• Generation-based fuzzing: Generates inputs from protocol/format specification Tools: AFL, libFuzzer, Peach Fuzzer, Boofuzz, RESTler, jsfuzz

Security Regression Testing

When: After every code change, before every deployment
What: Testing to ensure that changes have not broken existing security controls or introduced new vulnerabilities
Approach:

• Automated security unit tests for critical security functions
• Automated DAST baseline comparison (compare current scan to previous scan)
• Automated SAST comparison (new findings since last scan)
• Automated SCA comparison (new vulnerabilities since last build)
• Manual regression testing for security-critical workflows

Security Acceptance Criteria

Before an application is accepted into production, the following criteria must be met:

Tools, Technologies, and Solutions

SAST Tools

DAST Tools

SCA Tools

IAST Tools

Penetration Testing Tools

API Security Testing Tools

Mobile Security Testing Tools

AI/ML Security Testing Tools

Fuzzing Tools

Indian Penetration Testing Service Providers

Policy and Procedure Templates

Security Testing Policy (Template)

Security Test Plan Template (Template)

Risk Assessment and Treatment

Risk Assessment for Security Testing

Risk Treatment Options

Audit and Compliance Checklist

Pre-Audit Self-Assessment

Auditor Interview Questions

Be prepared to answer:

1. "What security testing is performed before applications go live?"
2. "Can you show me the security test report for [application]?"
3. "Who approves security testing results?"
4. "What happens if critical vulnerabilities are found before go-live?"
5. "How do you handle false positives from automated testing?"
6. "Are external penetration testers used? What are their qualifications?"
7. "How do you test API security?"
8. "How do you test mobile application security?"
9. "Are security tests repeated after vulnerability remediation?"
10. "How do you ensure testing environments don't compromise production?"

Common Audit Findings and How to Avoid Them

Metrics and KPIs

Process Metrics

Outcome Metrics

Dashboard Sample

┌─────────────────────────────────────────────────────────────────────┐
│              SECURITY TESTING IN DEVELOPMENT & ACCEPTANCE           │
│                    [Organization] — [Month Year]                    │
├─────────────────────────────────────────────────────────────────────┤
│  TESTING COVERAGE: 100%      ██████████████████████  Target: 100%  │
│  SAST COVERAGE: 100%         ██████████████████████  Target: 100%  │
│  DAST COVERAGE: 98%          ████████████████████░░  Target: 100%  │
│  SCA COVERAGE: 100%          ██████████████████████  Target: 100%  │
│  SIGN-OFF RATE: 100%         ██████████████████████  Target: 100%  │
│  SLA COMPLIANCE: 94%         ███████████████████░░░  Target: 90%  │
│  PROD VULN RATE: 1/q       █░░░░░░░░░░░░░░░░░░░░  Target: <2/q  │
│  MTTR (CRITICAL): 3.2 days  ███░░░░░░░░░░░░░░░░░░  Target: <7   │
│  FALSE POSITIVE: 15%         ███░░░░░░░░░░░░░░░░░░  Target: <20% │
│  TEST PASS RATE: 96%         ████████████████████░░  Target: 95%  │
└─────────────────────────────────────────────────────────────────────┘

Common Pitfalls and How to Avoid Them

Pitfall 1: "Testing Slows Down Deployment"

Symptom: Security testing is skipped or rushed to meet deadlines.

Reality: Testing prevents production vulnerabilities that overhead 100x more to fix. Automated testing in CI/CD adds minutes, not hours.

Solution:

• Automate testing in CI/CD (SAST, SCA run in minutes)
• Use parallel testing (DAST on staging while developers work on next feature)
• Streamline manual testing for low-risk changes
• Show time-to-fix data: testing vs. production

Pitfall 2: "We Only Need Penetration Testing"

Symptom: Organization relies solely on annual penetration tests.

Reality: Penetration testing is point-in-time and cannot cover all code changes. Automated testing (SAST, DAST, SCA) provides continuous coverage.

Solution:

• Use automated testing for continuous coverage
• Use penetration testing for deep, adversarial testing
• Combine both for complete security validation
• Test after every major change, not just annually

Pitfall 3: "Automated Tools Find Everything"

Symptom: Organization relies solely on SAST/DAST and skips manual testing.

Reality: Automated tools find known patterns but miss business logic flaws, race conditions, and novel vulnerabilities. Manual testing is essential.

Solution:

• Use automated tools for scale and consistency
• Use manual testing for business logic and adversarial scenarios
• Use red team exercises for realistic attack simulation
• Combine automated and manual for complete coverage

Pitfall 4: "We Tested It Once, It's Fine"

Symptom: Security testing is performed once at launch and never repeated.

Reality: New vulnerabilities are discovered constantly. Code changes, new dependencies, and new attack techniques create new risks.

Solution:

• Continuous testing in CI/CD (SAST on every commit, DAST on every deployment)
• Periodic penetration testing (quarterly for critical apps)
• Re-test when new CVEs affect your stack
• Annual complete security testing

Pitfall 5: "Test Environment Doesn't Matter"

Symptom: Testing is performed on environments that don't mirror production.

Reality: Vulnerabilities may be masked by configuration differences. A vulnerability in production may not be reproducible in a different environment.

Solution:

• Use Infrastructure as Code to ensure environment parity
• Validate environment configuration before testing
• Include configuration security testing in scope
• Test on production-like data volumes and loads

Pitfall 6: "We Only Test Our Code"

Symptom: Third-party components and APIs are not tested.

Reality: Third-party vulnerabilities are the #1 attack vector for many breaches. Log4j, Spring4Shell, and similar vulnerabilities were in third-party components.

Solution:

• SCA for all dependencies (every build)
• Penetration testing of third-party integrations
• Vendor security testing requirements
• Continuous monitoring for new CVEs affecting dependencies

Pitfall 7: "Vulnerabilities Can Wait"

Symptom: Medium and low vulnerabilities are never fixed.

Reality: Attack chains often combine medium vulnerabilities to achieve critical impact. Unpatched vulnerabilities accumulate into technical debt.

Solution:

• Fix all vulnerabilities within SLA, not just critical
• Use risk-based prioritization that considers attack chains
• Track vulnerability age as a KPI
• Include vulnerability remediation in sprint planning

Pitfall 8: "Security Testing Is the Security Team's Job"

Symptom: Developers write code and "throw it over the wall" to security for testing.

Reality: Developers who write code must own its security. Security testing validates developer work; it doesn't replace developer responsibility.

Solution:

• Developer-driven security testing (SAST in IDE, unit security tests)
• Security champion program
• Make security testing results visible to developers
• Reward teams with low vulnerability density

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian Fintech Startup, Security Testing Integration

Organization: A fintech startup in Bengaluru building a personal finance app. Context: 25 developers, React Native mobile app, Node.js backend, PostgreSQL database. 2 million users. RBI compliance required. Challenge: No security testing before deployment. First penetration test (after 2 years) revealed 42 critical vulnerabilities. Production had multiple SQL injection and authentication bypass issues. Approach:

1. Week 1-2: Singahi conducted security testing assessment. Baseline: zero automated testing, no pen testing, no acceptance criteria.
2. Week 3-4: Implemented SAST (Semgrep) in GitHub Actions CI/CD. Integrated Snyk for SCA. Set up OWASP ZAP for DAST on staging environment.
3. Week 5-6: Defined security acceptance criteria: zero critical SAST/DAST findings, zero critical CVEs, all high findings remediated or risk-accepted. Created security sign-off workflow.
4. Week 7-8: Conducted developer training on interpreting SAST findings and writing security unit tests. Trained 3 security champions.
5. Week 9-12: First quarterly penetration test conducted by Singahi. Found 8 critical vulnerabilities (down from 42). All remediated before next release. Established quarterly pen testing schedule. Results:

• Critical vulnerabilities in production: 0 (last 4 releases)
• SAST findings per release: 3 (down from 40+), all low/informational
• SCA critical CVEs: 0 (automated patching via Snyk)
• Security testing cycle time: 2 days (automated) + 5 days (manual pen test for major releases)
• Mean time to remediate critical: 1.5 days (down from 21 days)
• RBI compliance: achieved on first audit attempt
• Customer-reported vulnerabilities: 0 (down from 3 per quarter)
• impact of testing program: /year (tools + consulting)
• impact of potential breach: + (based on 2 million users × PII exposure) Key Lesson: Automated testing in CI/CD + periodic penetration testing + acceptance criteria = dramatic reduction in production vulnerabilities. The investment pays for itself with a single avoided breach.

Illustrative Scenario 2: Indian Healthcare Enterprise, Security Testing for EHR System

Organization: A hospital chain with 15 hospitals across India, implementing a new Electronic Health Record (EHR) system. Context: 500+ developers, Java/Spring Boot backend, Angular frontend, Oracle database. Integration with lab systems, pharmacy systems, and insurance portals. HIPAA and DPDP Act compliance required. Challenge: EHR system had no security testing program. HIPAA audit flagged "inadequate security validation." System processed PHI for 2 million+ patients. Integration points were untested for security. Approach:

1. Phase 1 (Month 1): Singahi established the Security Testing Policy and defined risk-based testing tiers. Critical tier (patient data systems): SAST + DAST + SCA + quarterly pen test + IAST.
2. Phase 2 (Months 2-3): Implemented Checkmarx for enterprise SAST, integrated into Jenkins. Implemented Sonatype Nexus Lifecycle for SCA. Implemented OWASP ZAP for DAST. Implemented Contrast Security for IAST on critical modules.
3. Phase 3 (Months 4-5): Defined security acceptance criteria for EHR modules: zero critical findings, all high findings remediated, all PHI access logged, all integrations pen-tested. Created security sign-off workflow with CISO approval.
4. Phase 4 (Months 6-8): Conducted complete penetration testing of EHR system and all 12 integration points. Found 15 critical vulnerabilities (integration points were the weakest). Remediated all before go-live.
5. Phase 5 (Months 9-12): Established quarterly penetration testing, monthly DAST, continuous SAST/SCA. Implemented security regression testing for all EHR updates. Trained 20 security champions across development teams. Results:

• Critical vulnerabilities in production: 0 (first 12 months post-implementation)
• HIPAA audit: zero findings on security testing
• DPDP Act compliance: demonstrated through complete testing documentation
• Patient data breaches: 0
• Integration security: all 12 integration points tested and approved
• Security testing coverage: 100% of EHR modules and integrations
• Mean time to remediate critical: 2.1 days
• impact of testing program: /year
• impact of potential HIPAA breach (2 million patients): + (based on HIPAA penalties and Indian patient trust impact) Key Lesson: Healthcare applications require the most rigorous security testing due to PHI sensitivity. Integration points are often the weakest link and must be specifically tested.

Multi-Framework Mapping

NIST SP 800-53 Rev 5 Mapping

COBIT 2019 Mapping

PCI DSS 4.0 Mapping

DPDP Act 2023 Mapping

OWASP SAMM Mapping

CIS Controls v8 Mapping

Regulatory and Industry Context

India

International

Roles and Responsibilities (RACI)

RACI Matrix for Security Testing

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed

Role Descriptions

Documentation and Evidence Requirements

Mandatory Documentation

Evidence for Audit

Continuous Improvement

Improvement Cycle

Plan → Implement → Measure → Review → Improve

Plan: Set targets for testing coverage, vulnerability density, MTTR, sign-off rate.

Implement: Deploy tests, execute testing, track vulnerabilities, obtain sign-offs.

Measure: Track KPIs, conduct surveys, analyze audit results, monitor incidents.

Review: Monthly metrics review, quarterly process review, annual complete review.

Improve: Update test plans, tune tools, enhance training, adopt new techniques, automate.

Improvement Triggers

Maturity Advancement Path

FAQ

Q1: What is the difference between SAST, DAST, and IAST?

A: SAST (Static Application Security Testing) analyzes source code without running it. DAST (Dynamic Application Security Testing) tests running applications by simulating attacks. IAST (Interactive Application Security Testing) instruments the application during runtime to combine the accuracy of SAST with the runtime context of DAST. Use SAST for code-level issues, DAST for runtime issues, and IAST for high-accuracy testing when you need both.

Q2: Do we need manual penetration testing if we have automated testing?

A: Yes. Automated tools find known patterns but miss business logic flaws, race conditions, and novel vulnerabilities. Penetration testing simulates real-world adversaries who think creatively. Both are essential for complete security.

Q3: How often should we conduct penetration testing?

A: Quarterly for critical applications, bi-annually for high-risk, annually for medium-risk. Also conduct penetration testing after major architecture changes, before go-live for new applications, and when new threat intelligence suggests new attack vectors.

Q4: What if security testing finds critical vulnerabilities right before go-live?

A: The application should not go live until critical vulnerabilities are fixed. If business pressure is extreme, implement compensating controls (WAF rules, additional monitoring, restricted access) and obtain CISO risk acceptance. However, the default position is: no go-live with critical vulnerabilities.

Q5: How do we handle false positives from SAST?

A: Document false positives with justification and suppress them in the tool. Tune rules for your technology stack. Train developers to recognize and report false positives. Track false positive rate as a KPI. Review suppression decisions quarterly.

Q6: What is the minimum viable security testing program?

A: For small organizations: SAST in CI/CD (free tools like Semgrep or SonarQube Community), SCA (free tools like OWASP Dependency-Check or Dependabot), manual code review for security-critical code, and annual penetration testing for critical applications.

Q7: How do we test API security?

A: Use API-specific DAST tools (StackHawk, Nuclei), manual API penetration testing (Burp Suite, Postman with security tests), and fuzzing (RESTler). Test all endpoints, all HTTP methods, all authentication mechanisms, and all user roles. Test for BOLA (Broken Object Level Authorization), injection, and rate limiting bypass.

Q8: How do we test mobile application security?

A: Use MobSF for automated scanning, Frida/Objection for runtime analysis, Burp Suite for network interception, and manual testing for business logic. Test local storage, network security, code obfuscation, biometric auth, and deep linking.

Q9: How do we test AI/ML application security?

A: Use adversarial strength testing (Foolbox, ART), prompt injection testing (for LLMs), model extraction testing, data poisoning testing, and bias testing. Test the full pipeline: data ingestion, training, model serving, and inference.

Q10: What is security regression testing?

A: Testing to ensure that code changes have not broken existing security controls or introduced new vulnerabilities. Includes automated security unit tests, DAST baseline comparison, and SAST new findings detection.

Q11: Should we test third-party code?

A: Yes. Use SCA for dependency vulnerabilities. Include third-party integrations in penetration testing scope. Test vendor APIs and webhooks. Require vendors to provide their own security test results.

Q12: What is the difference between vulnerability assessment and penetration testing?

A: Vulnerability assessment uses automated tools to find vulnerabilities. Penetration testing simulates real attacks to determine if vulnerabilities are exploitable and what impact they would have. Vulnerability assessment is broader; penetration testing is deeper and adversarial.

Q13: How do we integrate security testing into Agile/Scrum?

A: SAST and SCA run automatically in CI/CD on every commit. DAST runs after each sprint deployment to staging. Security testing is part of the Definition of Done. Penetration testing is scheduled for major releases. Security findings are tracked as sprint backlog items.

Q14: What is the role of QA in security testing?

A: QA teams can execute DAST, validate security fixes, and perform security regression testing. QA should include security test cases in their test plans. Security testing should be integrated into QA processes, not treated as a separate activity.

Q15: How do we measure security testing effectiveness?

A: Track production vulnerability rate, vulnerability density, MTTR, customer-reported vulnerabilities, compliance audit findings, and testing coverage. See Section 13 for a full KPI framework.

References and Further Reading

Standards and Guidelines

1. ISO/IEC 27001:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Management Systems, Requirements. ISO, 2022.
2. ISO/IEC 27002:2022, Information Security, Cybersecurity and Privacy Protection, Information Security Controls. ISO, 2022.
3. NIST SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations. NIST, 2020.
4. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment. NIST, 2008.
5. OWASP Testing Guide v4.2, Web Security Testing Guide. OWASP, 2020.
6. OWASP Top 10:2021, The Ten Most Critical Web Application Security Risks. OWASP, 2021.
7. OWASP Application Security Verification Standard (ASVS) v4.0.3. OWASP, 2023.
8. OWASP Software Assurance Maturity Model (SAMM) v2.0. OWASP, 2020.
9. CWE Top 25, Most Dangerous Software Weaknesses. MITRE, 2023.
10. PCI DSS v4.0, Payment Card Industry Data Security Standard. PCI SSC, 2022.
11. CIS Controls v8, Center for Internet Security, 2021.

Testing Methodologies and Books

12. "The Web Application Hacker's Handbook", Dafydd Stuttard and Marcus Pinto, Wiley, 2011.
13. "The Art of Software Security Assessment", Mark Dowd et al., Addison-Wesley, 2006.
14. "Penetration Testing: A Hands-On Introduction to Hacking", Georgia Weidman, No Starch Press, 2014.
15. "Hacking: The Art of Exploitation", Jon Erickson, No Starch Press, 2008.
16. "Metasploit: The Penetration Tester's Guide", David Kennedy et al., No Starch Press, 2011.
17. "The Tangled Web: A Guide to Securing Modern Web Applications", Michal Zalewski, No Starch Press, 2012.
18. OWASP Testing Guide, https://owasp.org/www-project-web-security-testing-guide/
19. OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/
20. NIST SP 800-115, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf

Training and Certification

21. certified (Offensive Security Certified Professional), Offensive Security, https://www.offensive-security.com/
22. certified (Certified Ethical Hacker), EC-Council, https://www.eccouncil.org/
23. GWAPT (certified Web Application Penetration Tester), SANS/certified, https://www.giac.org/
24. GPEN (certified Penetration Tester), SANS/certified, https://www.giac.org/
25. OSWE (Offensive Security Web Expert), Offensive Security, https://www.offensive-security.com/
26. eWPT (eLearnSecurity Web Application Penetration Tester), INE, https://ine.com/
27. Singahi AI/ML Security Master Course, /

Indian Regulatory Resources

28. Digital Personal Data Protection Act 2023, Government of India, 2023.
29. RBI Master Direction on Cyber Security Framework, Reserve Bank of India, 2024.
30. SEBI Cybersecurity and Cyber Resilience Framework, Securities and Exchange Board of India, 2023.
31. IRDAI Guidelines on Information and Cybersecurity, Insurance Regulatory and Development Authority of India, 2023.
32. IT Act 2000 (as amended), Ministry of Electronics and Information Technology, India.

Industry Research

33. IBM impact of a Data Breach Report 2024, IBM Security and Ponemon Institute, 2024.
34. Verizon Data Breach Investigations Report 2024, Verizon, 2024.
35. Gartner Market Guide for Application Security Testing, Gartner, 2024.
36. Forrester TEI of Application Security, Forrester Research, 2023.
37. BSIMM12, Building Security In Maturity Model. Synopsys, 2023.
38. OWASP Testing Guide v4.2, https://owasp.org/www-project-web-security-testing-guide/