Application Security Testing Services

Application security testing is the assessment of an application's own code, logic and interfaces for exploitable weakness — as distinct from testing the network or infrastructure it runs on. Done properly it is scoped against the OWASP Application Security Verification Standard (ASVS), which defines three verification levels and roughly 350 testable requirements, and combines automated scanning with manual testing for the business-logic flaws scanners cannot find. CyberSigma is CERT-In empanelled and PCI QSA authorised (CEMEA, Asia Pacific and the USA).

What ASVS is, and which level you need

ASVS — the OWASP Application Security Verification Standard — is the reference most mature application security programmes are scoped against. Version 5.0.0, released in May 2025, carries roughly 350 requirements across 17 chapters. It defines three verification levels, and choosing the right one is the single most consequential scoping decision:

• Level 1 — verified through black-box testing without source code access. It covers the most critical vulnerability classes, including the OWASP Top 10, and is the minimum defensible baseline for any internet-facing application.
• Level 2 — the standard level for applications handling sensitive business or personal data. It requires source code access and deeper testing, and is appropriate for most enterprise applications. This is where the majority of our engagements sit.
• Level 3 — maximum verification for critical applications in finance, healthcare, defence and critical infrastructure. It adds architecture review, threat modelling and code analysis on top of penetration testing.
• Scoping to a level above what your risk warrants wastes budget; scoping below it produces a report that does not answer the question your customer or regulator actually asked. We establish the level with you before quoting rather than defaulting to one.

What we test

Testing is manual-led against OWASP WSTG and NIST SP 800-115 methodology. A scanner runs first to cover breadth; the findings that matter almost always come from what a person does afterwards:

• Authentication and session management — credential handling, multi-factor implementation, session fixation and lifetime, and password reset flows, which remain one of the most reliably broken areas.
• Authorisation — vertical and horizontal privilege escalation, insecure direct object references, and function-level access control. This is the category scanners are worst at and attackers are best at.
• Business logic — workflows that can be completed out of order, values that can be manipulated client-side, and limits that are only enforced in the interface. No scanner finds these.
• Injection and input handling — SQL, NoSQL, command and template injection, deserialisation, and file upload handling.
• APIs — object and function level authorisation, mass assignment, excessive data exposure and rate limiting. Modern breaches concentrate here far more than in the rendered front end.
• Client-side — cross-site scripting, CSRF, CORS misconfiguration, and the security headers that mitigate them.
• Configuration and dependencies — secrets in source, verbose errors, outdated components with known vulnerabilities, and the build pipeline that ships them.

Where this sits alongside VAPT, mobile testing and SAST/DAST

These terms overlap and vendors use them loosely, so it is worth being precise about what you are buying:

• Application security testing assesses the application itself — its code paths, logic and APIs. That is this page.
• VAPT is the broader engagement, typically covering network and infrastructure alongside applications, and is what most Indian regulators specify by name. If your driver is an RBI, SEBI or IRDAI mandate, start there.
• Mobile application security testing is a distinct discipline — local storage, transport security, certificate handling, platform APIs and reverse engineering. We cover that separately.
• SAST and DAST are tools, not an assessment. They belong in your pipeline for continuous coverage; they do not substitute for a manual test, and a report that is only tool output is not an application security assessment.
• In practice most clients want continuous automated coverage plus a periodic manual test. We are happy to scope that combination rather than sell a single annual engagement.

What you receive, and how findings get closed

A report is only useful if a developer can act on it and an auditor can accept it:

• An executive summary stating business risk in plain terms, for the board, the customer or the regulator asking.
• Technical findings with reproduction steps, evidence, affected endpoints and CVSS-based severity, ordered so the highest risk is addressed first.
• Remediation guidance written for the team that has to implement it, referencing the specific ASVS requirement each finding maps to.
• A retest after remediation, and an updated report evidencing closure — because a finding is closed when a retest proves the fix works, not when a ticket is marked done.
• Where required, a report from a CERT-In empanelled organisation, which is the form many Indian tenders and regulated entities must have.

What is ASVS?

ASVS is the OWASP Application Security Verification Standard — an open standard defining testable requirements for application security. Version 5.0.0, released in May 2025, contains roughly 350 requirements across 17 chapters, organised into three verification levels from basic (L1) to advanced (L3). It is the reference most mature application security programmes scope their testing against.

What is the difference between application security testing and penetration testing?

Application security testing focuses on the application itself — its code paths, business logic, authorisation model and APIs. Penetration testing is broader and usually includes network and infrastructure. In India, VAPT is the term most regulators use and typically covers both. If a regulator or customer named a specific term in their requirement, tell us which and we will scope to it.

Which ASVS level should we test to?

Level 1 is the minimum defensible baseline for anything internet-facing. Level 2 suits most enterprise applications handling sensitive business or personal data and is where most of our engagements sit. Level 3 is for critical applications in finance, healthcare, defence and critical infrastructure, and adds architecture review and threat modelling. We agree the level with you during scoping rather than defaulting to one.

Do you need access to our source code?

For Level 1, no — it is verified through black-box testing. Level 2 and above expect source code access, because a reviewer who can read the authorisation logic finds flaws that black-box testing will miss. We work with whatever access you can provide, and we will tell you plainly what a restricted scope means for the assurance you get.

Can automated scanning replace a manual test?

No, and it is worth being direct about why. Scanners are good at breadth — known vulnerability classes, outdated components, missing headers. They are poor at authorisation flaws and effectively blind to business logic, which is where the findings that actually matter tend to live. Use scanning for continuous coverage and manual testing for assurance.

Do you test APIs separately from the web application?

They are scoped together but tested distinctly, because API weaknesses differ from rendered-front-end ones — object and function level authorisation, mass assignment, excessive data exposure and rate limiting. Given how much modern functionality sits behind APIs, a test that only exercises the interface misses most of the attack surface.

Is a retest included?

Yes. We retest remediated findings and issue an updated report, which is what a regulator, an enterprise customer or your own board will want to see. A finding is closed when a retest proves the fix works.