Control Definition
Whenever an organization builds or buys an application, it must work out the information security requirements that application has to meet, write them into the specification, and have them formally approved.
Control Objective
To ensure applications are designed and built with security controls from the beginning, prevent common vulnerabilities, establish secure development practices, and verify that purchased or custom applications meet organizational security standards before deployment.
What This Really Means
Application security requirements means defining what security features and protections must be built into software applications during development—input validation to prevent injection attacks, authentication and authorization controls, encryption for sensitive data, secure session management, audit logging, and protection against common web vulnerabilities (OWASP Top 10). For purchased software, it means evaluating vendor security before procurement.
Think of it like building codes for construction: before building a house, architects must incorporate fire exits, smoke detectors, proper electrical wiring, and structural safety. You do not add these after the house is built. Similarly, applications must have security requirements defined during design phase and security controls built-in during development, not bolted on after deployment.
This control requires you to establish secure development lifecycle (SDLC) including security requirements gathering, threat modeling, secure coding standards, code review, security testing, and vulnerability remediation before production release. For vendor applications, conduct security assessments, review vendor security certifications, and validate security controls through testing. The goal is applications that resist attacks by design rather than relying solely on perimeter defenses.
Why It Matters
Application vulnerabilities are among the most common attack vectors—year after year, industry breach reports trace a large share of incidents to web application exploits. Applications with poor security design create organizational risk no amount of network security can compensate for.
Without application security requirements, organizations face:
- •SQL Injection and Code Injection Attacks – Improperly validated user input allows attackers to execute malicious code, access databases directly, and steal or modify data
- •Authentication Bypass and Privilege Escalation – Weak authentication mechanisms, session management flaws, and broken access controls allow unauthorized access to admin functions and sensitive data
- •Cross-Site Scripting (XSS) and CSRF Attacks – Insufficient input sanitization allows attackers to inject malicious scripts stealing user sessions or performing unauthorized actions
- •API Security Vulnerabilities – Broken authentication, excessive data exposure, and rate limiting failures in APIs allow automated attacks and mass data extraction
- •Third-Party Component Vulnerabilities – Using libraries and frameworks with known vulnerabilities (Log4Shell, Struts vulnerabilities) exposes applications to remote code execution
- •Post-Deployment Expensive Remediation – Fixing security flaws after application is in production costs 10-100x more than building security in during development
Indian software companies exporting services and SaaS applications face additional scrutiny: international customers require SOC 2, ISO 27001 compliance demonstrating secure development practices; poor application security reputation damages business prospects.
Implementation Guidance
Establish Secure Development Lifecycle (SDLC) Policy
Integrate security into all development phases: Requirements phase (define security requirements based on data classification, regulatory needs, threat landscape), Design phase (threat modeling to identify attack surfaces, security architecture review), Development phase (secure coding standards, static code analysis), Testing phase (dynamic security testing, penetration testing), Deployment phase (security configuration verification), Maintenance phase (vulnerability monitoring, patch management). Document security gates that must be passed before code can proceed to next phase. Apply to both custom development and modifications to purchased applications.
Define Security Requirements for Applications
Specify mandatory security controls all applications must implement: Authentication (multi-factor for admin access, strong password policies, account lockout after failed attempts), Authorization (role-based access control, principle of least privilege, proper permission checks), Input validation (whitelist allowed inputs, reject malicious patterns, parameterized queries preventing SQL injection), Output encoding (prevent XSS attacks), Session management (secure session tokens, timeout after inactivity, logout functionality), Encryption (TLS for transit, encryption for sensitive data at rest), Audit logging (log authentication events, privilege changes, data access), Error handling (no sensitive information in error messages). Tailor requirements based on application risk level and data classification.
Implement Secure Coding Practices and Standards
Establish and enforce secure coding guidelines: Use OWASP Secure Coding Practices as baseline, adopt language-specific secure coding standards (Java, Python, JavaScript best practices), mandate input validation everywhere (never trust user input including from APIs, cookies, headers), use parameterized queries or ORM frameworks (never concatenate SQL), implement proper authentication and session management libraries (do not build custom crypto), sanitize outputs (encode HTML, JavaScript, SQL), avoid hard-coded secrets (use environment variables or secrets management), and maintain dependencies (use dependency scanners for known vulnerabilities). Provide secure coding training for all developers annually.
Conduct Threat Modeling and Security Architecture Review
Analyze security design before coding begins: Use STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) or PASTA (Process for Attack Simulation and Threat Analysis) to identify threats, create data flow diagrams showing how data moves through application, identify trust boundaries (where data crosses from trusted to untrusted zones), document security controls addressing each identified threat, and review architecture with security team before development starts. Update threat model when application functionality significantly changes. This front-loads security analysis when changes are cheap.
Perform Security Testing Throughout Development
Multi-layered testing approach: Static Application Security Testing (SAST) - analyze source code for vulnerabilities during development (SonarQube, Checkmarx, Veracode), Dynamic Application Security Testing (DAST) - test running application for vulnerabilities (OWASP ZAP, Burp Suite), Software Composition Analysis (SCA) - scan dependencies for known CVEs (Snyk, WhiteSource, OWASP Dependency-Check), manual code review - peer review focusing on security-critical code paths, penetration testing - simulate attacks before production release. Integrate SAST/DAST into CI/CD pipeline so every build is tested. No code reaches production without passing security tests.
Manage Third-Party Components and Dependencies
Control security risks from libraries and frameworks: Maintain inventory of all dependencies (package.json, pom.xml, requirements.txt), use Software Composition Analysis tools to identify vulnerable components, subscribe to vulnerability feeds (GitHub Security Advisories, CVE databases, vendor security bulletins), establish SLA for patching critical vulnerabilities (within 30 days or faster for actively exploited), pin dependency versions (avoid wildcard version ranges that auto-update to vulnerable versions), and remove unused dependencies reducing attack surface. Regularly update dependencies balancing security with stability.
Evaluate Security of Purchased or Vendor Applications
Before procuring third-party software, assess security: Request vendor security documentation (architecture diagrams, security certifications like ISO 27001, SOC 2 Type II, penetration test reports), review security features (authentication methods, encryption support, audit logging, API security), evaluate data handling (where is data stored, who has access, whether storage locations satisfy DPDPA obligations and any sector-specific data-residency rules), verify patch management (SLA for security updates, historical track record), conduct vendor risk assessment questionnaire, and perform acceptance testing including security testing on vendor application. Include security requirements in procurement contracts (notification of breaches, right to audit, indemnification for security failures).
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.26:
Documentation
- Secure Development Lifecycle (SDLC) policy defining security requirements
- Secure coding standards and guidelines provided to developers
- Threat model documentation for applications
- Application security testing reports (SAST, DAST, penetration tests)
- Vendor security assessment questionnaires and evaluation results
Interviews
- Development team about secure coding practices and security testing processes
- Application security team about threat modeling and architecture review
- Procurement team about vendor security assessment procedures
Observations
- Review of CI/CD pipeline showing integrated security testing tools
- Demonstration of code review process including security checks
- Verification that dependencies are scanned for vulnerabilities
- Testing application for common OWASP vulnerabilities
Practitioner Insights
A pattern that keeps repeating in breach investigations: customer financial data stolen through SQL injection because developers with no secure coding training concatenated user input directly into queries—a textbook vulnerability known since 1998. Even basic security testing catches it instantly. Investing in secure coding training and automated security testing costs far less than one data breach. Make security testing mandatory before any production deployment.
Many companies think buying penetration testing once a year is sufficient application security. It is not. Pen tests find issues after code is written when fixes are expensive. Shift left: use SAST during development catching issues when developers are actively working on that code, DAST in staging before production, and pen testing as final validation. Automated security testing in CI/CD pipeline catches most common vulnerabilities before pen testers even see the application.
Common Challenges & Solutions
Challenge
Developers resist security requirements claiming they slow down development and prevent innovation.
Solution
Change culture through leadership support and enablement: Executives must publicly prioritize security alongside features, integrate security into definition of done (code is not complete until it passes security tests), provide training so developers understand why security matters, use automated tools reducing manual burden (SAST in IDE giving real-time feedback), measure and communicate security improvement (track vulnerability reduction over time), and celebrate security wins. Make security teams enablers not gatekeepers—help developers build secure code efficiently rather than just rejecting insecure code.
Challenge
Security testing tools generate hundreds of findings and development team does not know which to fix first.
Solution
Implement risk-based prioritization: Critical severity findings in production code (remote code execution, SQL injection, authentication bypass) - fix immediately, High severity in production - fix within sprint, Medium severity - backlog, Low severity or findings in unused code - accept risk or defer. Use tools that reduce false positives (manually verify and mark false positives so they stop appearing), focus on exploitability (theoretical vulnerability vs. actually exploitable in your context), and track metrics (reduce critical/high findings each sprint). Do not aim for zero vulnerabilities—aim for manageable risk.
Challenge
Third-party vendors refuse to provide security documentation or allow security testing of their applications.
Solution
Negotiation leverage and alternatives: For critical vendors, include security requirements in procurement contract (right to security documentation, right to pen test or review third-party pen test reports, notification SLAs for security incidents), escalate to vendor management if needed, accept risk for non-critical vendors with documented approval, consider alternative vendors more willing to demonstrate security, or deploy vendor applications in isolated environments with strict access controls and monitoring reducing blast radius if vendor app is compromised. Walk away from critical vendors with poor security posture.
Challenge
We do not have budget for commercial security testing tools like Veracode or Checkmarx.
Solution
Leverage open-source and free tools: SAST - SonarQube Community Edition, Semgrep, DAST - OWASP ZAP (comprehensive free web app scanner), Dependency scanning - OWASP Dependency-Check, Snyk free tier, GitHub Dependabot, Container scanning - Trivy, Clair, Secret scanning - TruffleHog, GitGuardian. These tools provide significant security value at zero cost. Commercial tools add better UX, support, and accuracy but open-source tools are sufficient for many organizations. Invest time in configuring and tuning tools rather than buying expensive tools that sit unused.
Challenge
Legacy applications were built without security requirements and are too complex/critical to rewrite.
Solution
Implement compensating controls and incremental improvement: Deploy Web Application Firewall (WAF) protecting legacy app from common attacks (SQL injection, XSS), implement additional authentication layer (SSO, MFA) in front of legacy app, isolate legacy app on network segment with strict firewall rules, monitor application logs for suspicious activity, conduct regular penetration testing to identify exploitable vulnerabilities and patch if possible, plan gradual modernization (replace modules incrementally rather than full rewrite), and document accepted risks with management approval. For ultra-critical legacy apps, consider application wrapping/security gateway approaches.
