OWASP Top 10:2025, Secure SDLC, DevSecOps and Practical AppSec Scenarios
Application Security interviews have moved far beyond asking candidates to define SQL injection or cross-site scripting. Employers now expect professionals to understand how security fits into architecture, development, testing, deployment and production operations.
A strong candidate should be able to explain how vulnerabilities arise, how attackers exploit them, which preventive controls developers should use and how those controls can be verified. The strongest answers also recognise that scanners cannot find every design flaw, access-control weakness or business-logic abuse.
This guide covers 25 frequently asked Application Security interview questions and answers for 2026. It is suitable for Application Security Engineers, Product Security Engineers, DevSecOps professionals, penetration testers, security analysts, developers and anyone preparing to build a career in secure software development.
Important 2026 context: The current released OWASP Top 10 is the 2025 edition, and the latest stable OWASP Application Security Verification Standard is ASVS 5.0.0. NIST SP 800-218 SSDF Version 1.1 remains the current final Secure Software Development Framework; SSDF Version 1.2 was published as a draft and should not be described as final unless NIST updates its status.
Interview tip: Do not answer only with tool names. Begin with the risk, explain the control, identify where it belongs in the software lifecycle and describe how you would test its effectiveness.
Quick application-security testing reference
| Method | What it examines | When it is useful | Important limitation |
| SAST | Source code, bytecode or binaries without running the application | During coding and CI builds | May produce false positives and may lack runtime context |
| DAST | A running application from the outside | Test or staging environments | Usually cannot see the exact vulnerable code path |
| SCA | Open-source libraries, packages and dependency metadata | From development through production | A known vulnerable version does not automatically prove exploitability |
| IAST | Application behaviour through runtime instrumentation during testing | Functional or integration testing | Coverage depends on which code paths the tests execute |
| Manual review and penetration testing | Design, code, workflows and attacker behaviour | High-risk features and pre-release assurance | Requires skilled people and cannot test every possible state |
No single technique provides complete coverage. Mature teams combine them according to application risk and delivery speed.
1. What is Application Security?
Application Security, or AppSec, is the practice of identifying, preventing, detecting and responding to security weaknesses throughout the software lifecycle.
It covers:
- security requirements and architecture;
- threat modelling and secure design;
- secure coding and peer review;
- application, API and dependency testing;
- secrets and software supply-chain protection;
- secure deployment and configuration;
- vulnerability management; and
- production monitoring and incident response.
Application Security focuses on how software is designed and behaves. Network security may restrict traffic to an application, but it cannot correct a server-side authorisation flaw that lets one customer read another customer’s records. Similarly, a web application firewall may block some malicious inputs, but it does not replace secure code and design.
Strong interview point: AppSec is a continuous risk-management discipline shared by engineering, security, product and operations—not a penetration test performed just before release.
2. What is a Secure Software Development Life Cycle?
A Secure Software Development Life Cycle, or Secure SDLC, integrates security activities into every stage of software delivery.
A practical Secure SDLC includes:
- Planning: Define security, privacy and compliance requirements.
- Design: Model threats, review architecture and select secure patterns.
- Development: Apply coding standards, peer review, secret scanning and secure libraries.
- Build: Protect repositories, build systems, dependencies and artefact integrity.
- Testing: Use SAST, DAST, SCA, security unit tests and risk-based manual testing.
- Release: Verify approvals, configurations, provenance and unresolved risk.
- Operations: Monitor attacks, manage vulnerabilities and protect runtime environments.
- Improvement: Analyse incidents and recurring weaknesses to prevent entire classes of defects.
NIST SP 800-218 groups its final SSDF Version 1.1 practices into preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities.
Strong answer: “The Secure SDLC adds repeatable security outcomes to the existing delivery process instead of creating a separate process that teams can bypass.”
3. What do “shift left” and “shift everywhere” mean in AppSec?
Shift left means performing security activities earlier in the software lifecycle. Examples include defining security requirements during planning, threat modelling before implementation and scanning code or dependencies during development.
Finding a design flaw before coding is usually faster and less expensive than correcting it after release. Developers also receive feedback while the relevant code is still familiar.
However, early testing is not sufficient. Shift everywhere recognises that security must continue across build, deployment and production because:
- infrastructure and configurations change;
- not every code path is covered before release;
- new dependency vulnerabilities emerge;
- credentials can be exposed after deployment;
- attacker behaviour provides runtime evidence; and
- business context changes over time.
A balanced approach combines developer-friendly early controls with secure CI/CD, deployment guardrails, runtime monitoring, penetration testing and a response process.
Common mistake: Treating shift left as transferring all security responsibility to developers. Security teams must provide usable standards, training, secure components and timely support.
4. What is the OWASP Top 10:2025?
The OWASP Top 10:2025 is an awareness document describing major web-application security risk categories. The current list is:
- A01:2025 — Broken Access Control
- A02:2025 — Security Misconfiguration
- A03:2025 — Software Supply Chain Failures
- A04:2025 — Cryptographic Failures
- A05:2025 — Injection
- A06:2025 — Insecure Design
- A07:2025 — Authentication Failures
- A08:2025 — Software or Data Integrity Failures
- A09:2025 — Security Logging and Alerting Failures
- A10:2025 — Mishandling of Exceptional Conditions
Important changes from the 2021 edition include the broader Software Supply Chain Failures category and the new focus on Mishandling of Exceptional Conditions. Server-Side Request Forgery is incorporated into the Broken Access Control category.
The Top 10 is a useful awareness and prioritisation starting point, but it is not a complete testing standard. An application can avoid the ten categories and still contain serious business-logic, privacy or platform-specific risks.
5. What is the difference between the OWASP Top 10 and OWASP ASVS?
The OWASP Top 10 is an awareness document that highlights major categories of web-application risk. It helps teams understand common problem areas but does not provide a complete set of verification requirements.
The OWASP Application Security Verification Standard, or ASVS, provides detailed, testable requirements for application security controls. The latest stable version is ASVS 5.0.0.
ASVS can be used to:
- define application security requirements;
- design test cases;
- evaluate technical controls;
- establish security expectations in procurement; and
- create a consistent basis for internal and external assessments.
Example: The Top 10 may tell a team that broken access control is a major risk. ASVS provides specific requirements that can be mapped to architecture, implementation and testing.
Strong interview point: Use the Top 10 for awareness and risk communication; use ASVS or an equivalent detailed standard to build measurable requirements and verification coverage.
6. What is threat modelling, and when should it be performed?
Threat modelling is a structured process for understanding a system, identifying how it could be attacked and deciding how to reduce the resulting risk.
A practical threat model asks four questions:
- What are we building?
- What can go wrong?
- What will we do about it?
- Did we address the important risks effectively?
Teams typically document users, services, data stores, external dependencies, trust boundaries and data flows. They then examine threats using approaches such as STRIDE, attack trees, abuse cases or scenario-based analysis.
Threat modelling should begin during design and be updated when important architecture, data, trust or workflow changes occur. It is especially valuable for authentication, payments, administrative features, sensitive data, multi-tenant systems and new external integrations.
The output should include prioritised threats, mitigations, owners, assumptions and residual risk—not merely a diagram.
Strong answer: “Threat modelling helps find design and business-logic risks that automated scanners may never see.”
7. What do secure by design and secure by default mean?
Secure by design means security objectives and attacker behaviour influence the architecture before implementation. The product should use patterns that eliminate or reduce vulnerability classes instead of depending primarily on customers or operations teams to compensate later.
Secure by default means the product starts in a reasonably protected state without requiring users to discover and enable essential controls. Examples include:
- denying access unless it is explicitly granted;
- requiring strong authentication for administrative functions;
- disabling unnecessary services and debug features;
- using safe cookie and transport settings;
- avoiding default passwords;
- limiting data exposure in logs and errors; and
- choosing restrictive sharing and permission settings.
Security should also be usable. If a control makes normal work extremely difficult, people may find unsafe workarounds.
CISA’s Secure by Design guidance encourages software manufacturers to treat customer security as a core business requirement and to reduce entire classes of preventable defects.
Interview point: Secure by design concerns architecture and product decisions; secure by default concerns the initial and standard configuration experienced by users.
8. What is the difference between authentication and authorisation?
Authentication verifies who a user or service is. Passwords, passkeys, certificates, one-time codes and federated identity tokens are examples of authentication mechanisms.
Authorisation determines what an authenticated identity is allowed to do. It should consider the requested action, target resource, ownership, role, tenant and relevant context.
An application can authenticate correctly and still be critically vulnerable if authorisation is missing. For example, a user may log in legitimately but change an account identifier in an API request to retrieve another customer’s data.
Recommended practices include:
- centralise reusable server-side access-control logic;
- deny access by default;
- validate permissions for every sensitive request;
- enforce object ownership and tenant boundaries;
- avoid trusting hidden fields or client-side controls; and
- test positive and negative authorisation cases.
Strong interview point: Authentication answers “Who are you?” Authorisation answers “May you perform this action on this specific resource right now?”
9. What is Broken Access Control, and how can it be prevented?
Broken Access Control occurs when an application fails to enforce restrictions on what a user or service may view, change or execute. It is A01 in the OWASP Top 10:2025.
Examples include:
- Insecure Direct Object Reference or Broken Object Level Authorisation;
- a standard user accessing an administrative endpoint;
- changing another user’s record by modifying an identifier;
- missing authorisation on POST, PUT or DELETE APIs;
- trusting roles or prices supplied by the browser;
- weak tenant isolation; and
- manipulating tokens or workflow state to gain privilege.
Prevention requires trusted server-side enforcement, deny-by-default policies, reusable access-control components and checks at both function and object level. Resource ownership and business limits should be enforced in the domain or service layer.
Automated tests should verify that unauthenticated, ordinary, privileged and cross-tenant users receive the correct result for every sensitive action.
Common mistake: Hiding an administrator button in the user interface. An attacker can call the backend endpoint directly.
10. What is injection, and how do you prevent it?
Injection occurs when untrusted input is interpreted as part of a command, query or expression. It can affect SQL, NoSQL, operating-system commands, LDAP, templates and other interpreters.
The primary defence is to keep data separate from executable instructions. Depending on the technology, this includes:
- parameterised queries or prepared statements;
- safe APIs that avoid building commands with string concatenation;
- allow-list validation for expected values;
- context-appropriate encoding where an interpreter requires it;
- least-privilege database and operating-system accounts; and
- avoiding dynamic evaluation functions.
Input validation is valuable, but it should not replace parameterisation. Escaping is also context-specific and easy to implement incorrectly.
Example: A database query should bind a supplied account number as a value. It should never concatenate the number directly into the SQL statement.
CISA and the FBI have urged manufacturers to eliminate SQL injection as a preventable vulnerability class.
Strong answer: “Validate input for business correctness, parameterise the interpreter boundary and limit the impact if a control fails.”
11. What is Cross-Site Scripting, and how can it be prevented?
Cross-Site Scripting, or XSS, occurs when attacker-controlled content is executed as active script in another user’s browser under the application’s origin.
The main categories are:
- Stored XSS: Malicious content is saved and later delivered to users.
- Reflected XSS: Input is immediately returned in an unsafe response.
- DOM-based XSS: Client-side code places untrusted data into a dangerous browser sink.
Prevention includes:
- use framework features that escape output by default;
- apply context-aware output encoding for HTML, attributes, JavaScript, CSS and URLs;
- sanitise intentionally allowed HTML with a maintained library;
- avoid unsafe DOM APIs and dynamic code execution;
- validate URL schemes and untrusted content; and
- deploy a carefully designed Content Security Policy as defence in depth.
HTTP-only cookies can reduce theft of session cookies but do not prevent XSS or all of its consequences.
Common mistake: Using one generic encoding function for every output context. Security depends on where the data is inserted.
12. What is Cross-Site Request Forgery, and how is it prevented?
Cross-Site Request Forgery, or CSRF, tricks a user’s authenticated browser into sending an unwanted request to an application. The attack works when the browser automatically attaches credentials, such as session cookies, and the server cannot distinguish the attacker’s request from the user’s intended action.
Defences include:
- anti-CSRF tokens tied to the session or request;
- SameSite cookie settings appropriate to the application;
- Origin or Referer validation for sensitive requests;
- re-authentication or transaction confirmation for high-risk actions;
- avoiding state changes through GET requests; and
- protecting cross-origin access with a restrictive CORS policy.
SameSite cookies provide useful protection but may not suit every workflow and should not automatically be the only control. Applications using tokens in an Authorisation header rather than automatically attached cookies may have a different CSRF exposure, but XSS and token-storage risks still require attention.
Strong interview point: CSRF abuses the browser’s authority to send credentials; XSS executes attacker-controlled content within the application’s origin.
13. What is Server-Side Request Forgery?
Server-Side Request Forgery, or SSRF, occurs when an attacker causes a server to make a request to an unintended destination. The application may expose functionality that retrieves a URL, imports a file, processes a webhook, generates a preview or connects to an external service.
An attacker may use SSRF to:
- access internal services unavailable from the internet;
- query cloud instance metadata;
- scan internal networks;
- retrieve sensitive files or credentials; or
- send requests from a trusted application identity.
Defences include:
- allow-list approved destinations and protocols where possible;
- parse and normalise URLs with trusted libraries;
- resolve and validate destinations carefully, including redirects;
- block loopback, link-local, private and metadata addresses when not required;
- separate high-risk retrieval services from sensitive networks;
- restrict outbound traffic; and
- use modern cloud metadata protections and narrowly scoped workload identities.
Strong answer: Input validation is necessary, but network egress controls and identity least privilege reduce the impact if validation is bypassed.
14. How should sessions and JWTs be secured?
For server-managed sessions:
- generate unpredictable session identifiers;
- send cookies only over HTTPS;
- set Secure, HttpOnly and appropriate SameSite attributes;
- rotate the session identifier after authentication or privilege changes;
- enforce inactivity and absolute timeouts;
- invalidate sessions on logout and important account changes; and
- avoid putting sensitive data in the identifier.
For JSON Web Tokens, or JWTs:
- verify the signature using an explicitly approved algorithm;
- validate issuer, audience, expiry and other required claims;
- use short lifetimes;
- protect signing keys and rotate them safely;
- never accept an unsigned token where authentication is required;
- avoid storing unnecessary sensitive data in the payload; and
- design revocation or session termination for the application’s risk.
JWT payloads are encoded, not automatically encrypted. Anyone holding a typical signed JWT may be able to read its claims.
Common mistake: Trusting a role claim without validating the token’s signature, issuer, audience and current authorisation state.
15. What are common cryptographic failures in applications?
Cryptographic failures occur when sensitive data is not adequately protected or cryptography is used incorrectly.
Examples include:
- transmitting sensitive information without TLS;
- using outdated algorithms or weak parameters;
- hard-coding encryption keys;
- reusing nonces or initialisation vectors incorrectly;
- storing passwords with fast general-purpose hashes;
- failing to validate certificates;
- exposing sensitive data in URLs, logs or caches; and
- designing custom cryptographic algorithms or protocols.
Applications should classify data, minimise collection, use maintained cryptographic libraries and follow approved organisational standards. Passwords should be processed with a suitable adaptive password-hashing function and unique salts. Encryption keys should be stored separately from encrypted data, restricted, rotated where appropriate and monitored.
Encryption does not replace access control. A compromised application identity that is authorised to decrypt data may still expose it.
Strong interview point: Cryptography fails more often through poor key management, unsafe implementation and incorrect assumptions than through an attacker mathematically breaking a modern algorithm.
16. What is the difference between SAST, DAST and IAST?
Static Application Security Testing (SAST) examines code or compiled artefacts without executing the application. It can provide early feedback and identify the exact code location, but it may generate false positives or miss runtime behaviour.
Dynamic Application Security Testing (DAST) tests a running application from the outside. It can identify exploitable behaviours and configuration issues, but it usually has limited visibility into the code and may not cover authenticated or complex workflows without configuration.
Interactive Application Security Testing (IAST) observes the application from inside the runtime while functional tests exercise it. This combines code and runtime context, but coverage depends on which paths the tests execute.
These methods are complementary. A mature pipeline may run fast SAST checks on pull requests, broader SAST and SCA during builds, DAST against a deployed test environment and targeted manual testing for critical features.
Strong answer: “Tool results show potential evidence. I still validate exploitability, reachability, control context and business impact before deciding priority.”
17. What are SCA and SBOM, and how do they support supply-chain security?
Software Composition Analysis (SCA) identifies third-party and open-source components, versions, licences and known vulnerabilities. It may also analyse transitive dependencies that applications inherit indirectly.
A Software Bill of Materials (SBOM) is an inventory of software components and their relationships. It supports visibility, vulnerability response and supplier communication, particularly when a new issue affects a widely used package.
Effective software supply-chain security also requires:
- approved package sources and repository controls;
- dependency pinning and integrity verification;
- protected developer and CI/CD identities;
- isolated, reproducible or controlled builds where appropriate;
- signed artefacts and verified provenance;
- review of install scripts and high-risk updates;
- rapid dependency inventory searches; and
- ownership and remediation processes.
An SBOM does not prove that software is secure, and an SCA finding does not automatically prove that a vulnerable function is reachable. Teams should combine version information, exploitability, exposure, application use and available mitigations.
The OWASP Top 10:2025 broadens this concern under A03 Software Supply Chain Failures.
18. How should secrets be managed in application development?
Secrets include passwords, API keys, tokens, signing keys, private certificates and other credentials used by software.
Recommended practices include:
- never hard-code secrets in source code, configuration committed to a repository or container images;
- use a dedicated secrets-management service;
- prefer short-lived workload identities over permanent credentials;
- give each application and environment separate, least-privilege access;
- inject secrets securely at runtime;
- prevent secret values from appearing in logs and error reports;
- scan repositories, commits, build output and artefacts;
- rotate secrets automatically where practical; and
- monitor retrieval and unusual use.
If a secret is committed to a repository, removing the line in a later commit is not sufficient. The organisation should revoke or rotate the secret immediately, investigate its use and address repository history and cached copies where appropriate.
Strong interview point: The most effective secret is one the application never has to store because the platform can issue a short-lived identity token.
19. How do you secure APIs?
API security requires protection at transport, identity, object, function and business-logic levels.
Important controls include:
- use TLS and validate tokens correctly;
- enforce authorisation for every object and action;
- validate schemas, data types, ranges and content sizes;
- minimise returned fields to prevent excessive data exposure;
- apply rate limits, quotas and anti-automation controls based on business risk;
- restrict mass assignment to explicitly permitted fields;
- maintain an inventory of API versions and endpoints;
- remove or protect deprecated and test APIs;
- keep secrets and sensitive data out of URLs;
- validate webhooks and third-party callbacks; and
- log security-relevant activity without exposing credentials.
An API gateway can centralise authentication, routing, rate limits and visibility, but it cannot understand every resource-ownership rule or transaction state. Application services must still enforce domain-specific authorisation and business rules.
Example: A payment API should not trust the price, discount, role or account ownership supplied by a mobile application. The server must derive and verify them.
20. How would you integrate security testing into a CI/CD pipeline?
The objective is fast, relevant feedback without making the pipeline unusable.
A risk-based design may include:
- pre-commit or pull-request secret scanning;
- lightweight SAST, linting and security unit tests for changed code;
- SCA and licence checks during dependency resolution;
- infrastructure and container configuration checks;
- broader SAST and build-integrity verification during CI;
- deployment of the application to an isolated test environment;
- API and DAST checks against important workflows;
- artefact signing and provenance verification; and
- controlled approval for production release.
Blocking rules should be based on severity, confidence, exploitability, asset criticality and organisational policy. Critical hard-coded credentials or a verified remote-code-execution path may justify an immediate block. Lower-confidence findings may enter a tracked triage workflow.
Exceptions should have an owner, documented reason, compensating controls and expiry date.
Strong interview point: Measure feedback time and false positives. Developers will bypass a control that is consistently slow, noisy or unactionable.
21. How do you triage and prioritise application-security findings?
Scanner severity alone should not determine remediation order. Triage should consider:
- whether the finding is valid and reproducible;
- whether vulnerable code is reachable;
- internet or internal exposure;
- required authentication and privilege;
- exploit availability and attacker complexity;
- data sensitivity and business function;
- possible confidentiality, integrity and availability impact;
- affected customer or tenant scope;
- existing preventive, detective and compensating controls; and
- evidence of active exploitation.
A lower-scored authorisation flaw in a payment workflow may represent greater business risk than a technically high-severity issue in unreachable test code.
The finding should contain evidence, affected component and version, realistic attack scenario, business impact, remediation guidance and a responsible owner. Security and engineering should agree on timelines based on risk.
Strong answer: “I combine technical severity with exploitability and business context, validate the issue, assign ownership and track it through remediation and retesting.”
22. What should a secure code review look for?
Secure code review examines whether an implementation follows expected security controls and handles untrusted data safely.
Reviewers should focus on:
- authentication, authorisation and tenant boundaries;
- input validation and output handling;
- queries, commands and template rendering;
- session, token and cookie behaviour;
- cryptographic use and key handling;
- file upload, path and archive processing;
- URL retrieval and outbound requests;
- deserialisation and dynamic execution;
- error handling and fail-safe behaviour;
- sensitive data in logs or responses;
- concurrency, state transitions and business rules; and
- dangerous framework or platform APIs.
The review should follow data from its source to sensitive sinks and verify controls at trust boundaries. Reviewers also need business context: code can be memory-safe and injection-free yet still allow a user to approve their own refund.
SAST can help locate patterns, but a skilled reviewer can evaluate intent, design and multi-step workflows that tools may not understand.
23. Can a Web Application Firewall replace secure coding?
No. A Web Application Firewall, or WAF, is a useful defence-in-depth control, but it cannot replace secure design, code and configuration.
A WAF may:
- detect or block known malicious request patterns;
- provide virtual patching while a code fix is developed;
- rate-limit abusive traffic;
- reduce common automated attacks; and
- improve visibility into internet-facing requests.
However, it may not reliably detect:
- broken object-level authorisation;
- business-logic abuse;
- attacks using valid application workflows;
- vulnerabilities in non-HTTP components;
- second-order injection; or
- malicious activity by trusted or internal identities.
Attackers may also alter encoding, request structure or behaviour to bypass rules. Broad rules can create false positives and affect legitimate customers.
Strong interview answer: “I may use a WAF rule as immediate risk reduction, but I would still fix the root cause, test the change and monitor for exploitation.”
24. Scenario: A tester finds that changing an order ID reveals another customer’s order. What would you do?
This is likely Broken Object Level Authorisation—often described as IDOR in web applications.
I would:
- validate the issue using controlled test accounts and avoid accessing unnecessary real customer data;
- identify affected endpoints, operations, roles and tenants;
- determine whether records can be read, changed or deleted;
- preserve relevant evidence and review access logs for possible exploitation;
- implement server-side authorisation based on the authenticated user and resource ownership;
- avoid relying on unpredictable identifiers as the primary control;
- add negative tests for cross-user, cross-role and cross-tenant access;
- review similar endpoints and shared access-control components;
- assess data-protection, contractual and incident-notification implications; and
- retest the fix before closing the finding.
A safer implementation retrieves or updates the order through both its identifier and the authorised customer’s scope, with a central policy enforcing the relationship.
Strong interview point: Changing a sequential ID to a UUID makes guessing harder but does not correct missing authorisation.
25. Scenario: A critical vulnerability is announced in a dependency used by production. How would you respond?
I would use a structured vulnerability-response process:
- validate the advisory, affected package names and versions through trusted sources;
- use SCA, SBOM and build records to identify affected applications and transitive dependencies;
- determine whether the vulnerable component and function are present, reachable and exposed;
- assess exploit availability, privileges, data and business impact;
- search logs and telemetry for signs of attempted or successful exploitation;
- apply immediate mitigations such as disabling a feature, restricting access or adding a narrowly tested WAF rule where appropriate;
- upgrade to a trusted fixed version or apply the vendor’s approved patch;
- rebuild through the secured pipeline rather than modifying production manually;
- test compatibility and verify the deployed artefact and dependency version; and
- document lessons about inventory, update speed, architecture and supplier risk.
If no fix exists, the risk owner should make a time-bound, evidence-based decision about mitigation, isolation or service suspension.
Strong interview point: A version match establishes potential exposure; reachability, configuration and runtime evidence help determine actual risk.
How to Answer Application Security Interview Questions Effectively
Use this four-part structure:
- Define the risk clearly. Explain the security failure in simple language.
- Describe the attack path. Show how untrusted input, identity or state reaches a sensitive action.
- Explain prevention and defence in depth. Cover design, implementation, testing and runtime controls.
- Describe verification. Explain how you would test the fix and prevent recurrence.
For scenario questions, organise the answer as: validate, limit unnecessary exposure, determine scope, preserve evidence, contain, correct the root cause, test and improve the wider control.
Final Takeaway
The strongest Application Security candidates understand both attacker behaviour and software engineering. They know that secure applications require more than scanners, WAF rules or an annual penetration test.Learn the principles behind authentication, authorisation, untrusted-data handling, secure design and supply-chain protection. Practise connecting each vulnerability to its root cause, business impact and verification method. That is what turns theoretical AppSec knowledge into practical security judgement.
