Security Testing Services in India

SAST, DAST, IAST and SCA: What Each One Genuinely Catches

These four acronyms get sold as if they were competing products. They are not. They look at different things, at different times, and each is blind in a way the others are not. Buying one and calling it security testing is how teams end up confident and exposed at the same time.

SAST: reading the code without running it

Static application security testing parses your source and follows data from where it enters the program to where it does something dangerous. Semgrep, CodeQL, SonarQube and Checkmarx all work on this principle, as do the language-specific tools: Bandit for Python, gosec for Go, Brakeman for Rails, find-sec-bugs for Java.

What it genuinely catches: injection built by string concatenation, unsafe deserialisation, hardcoded credentials, weak cryptographic primitives, path traversal, and the long tail of framework misuse where a supposedly safe API is called in an unsafe mode. Where it is strong, it is very strong, because it sees every path including the ones nobody exercises in testing.

What it misses: anything that depends on runtime state or configuration. It does not know your reverse proxy strips a header, that your ORM parameterises the query it is worried about, or that the endpoint it flagged is behind an authentication middleware. It also has no concept of who is allowed to do what. The false positive rate is the price of seeing every path, and it is the single reason SAST gets switched off.

The practical trade-off is speed against depth. Semgrep runs on a diff in seconds and is easy to write custom rules for, which makes it the right tool in a pull request. CodeQL does deeper interprocedural analysis and is correspondingly slower, which makes it the right tool nightly or on merge. Running the deep tool on every push is a common and self-defeating choice.

DAST: attacking the running application

Dynamic testing throws requests at a deployed instance and looks at what comes back. OWASP ZAP and Burp Suite are the tools most teams end up with, with Nuclei increasingly used for templated checks against known issues.

What it genuinely catches: things that only exist once the system is assembled. Missing security headers, TLS misconfiguration, cookies without the Secure or HttpOnly flags, verbose error pages leaking stack traces, directory listing left enabled, an admin panel reachable from the internet, reflected cross-site scripting that survives your actual template layer.

What it misses: everything it cannot reach. An unauthenticated DAST scan of an application where ninety percent of the surface is behind a login is testing the login page. This is the most common way DAST is wasted, and fixing it is unglamorous work: supply the scanner with valid sessions, teach it how to re-authenticate when it logs itself out by hitting the sign-out link, and exclude the destructive endpoints so it does not empty your staging database halfway through.

Single-page applications make this harder again. A crawler that only follows anchor tags will find almost nothing in a React or Vue front end, so the scan has to be driven from the API contract instead. If you have an OpenAPI specification, that becomes the map, which is one of several reasons a stale specification is a security problem rather than a documentation one.

IAST: instrumenting the application while it is tested

Interactive testing puts an agent inside the running application, usually as a language runtime hook, and watches what actually happens while your existing functional tests exercise it. Contrast Security and Seeker are the usual commercial names.

The appeal is real: because the agent sees the concrete data flow at runtime, it can tell you that this specific request reached this specific sink with attacker-controlled input, which cuts the false positive rate hard compared with pure static analysis. It also reports the line of code, which DAST cannot.

Where it is wrong: IAST only sees the code your tests exercise, so its coverage is exactly your functional test coverage and no better. If your integration suite touches sixty percent of routes, forty percent of the application is invisible to it. It also needs an agent in the runtime, which some teams will not accept in any environment they care about, and it is limited to the languages the vendor supports. We recommend it when there is a strong existing test suite to piggyback on and licence budget exists. We do not recommend it as a first purchase.

SCA: the code you did not write

Software composition analysis resolves your dependency tree and compares it against vulnerability databases. OWASP Dependency-Check, OSV-Scanner, Grype, Trivy and Snyk all do a version of this, and Dependabot or Renovate handle the upgrade side.

What it genuinely catches: known vulnerabilities in known versions, including in transitive dependencies you never chose. Given that most modern applications are mostly other people's code, this is usually where the largest raw finding count lives.

What it misses: anything not yet in a database, anything in a vendored or copy-pasted library that no manifest records, and the whole question of whether the vulnerable function is ever called. A critical CVE in a code path your application never reaches is not a critical risk to you, and treating it as one is how teams burn a sprint on upgrades that change nothing. Reachability analysis, where the tool checks whether the vulnerable symbol appears in your call graph, is the feature worth paying for here.

What none of them catch

Business logic. All four tools are looking for patterns, and a logic flaw has no pattern. A discount code that can be applied twice, a refund flow that can be triggered after the goods have shipped, a rate limit on the login endpoint but not on the password reset endpoint, an object identifier that can be incremented. These are found by a person who understands what the application is for, reading the code and probing the running system with intent. That is why the tooling and the human work are complementary, and why a page selling you scanners as complete coverage is selling you something false.

Dependencies, Transitive Risk and the Supply Chain

Most of what runs in production was written by people you have never met. A modest Node service can pull in several hundred packages once the tree is resolved, and you chose perhaps fifteen of them. Everything else arrived because something you chose depended on it. That is the actual attack surface, and it behaves differently from your own code.

Direct and transitive are different problems

A vulnerability in a direct dependency is usually straightforward: upgrade it, run the tests, ship. A vulnerability three levels down is not, because you cannot upgrade it directly. You need whichever intermediate package pins it to release a version that moves the pin, and that maintainer may be unresponsive, or the fix may be in a major version that breaks the intermediate's API.

The escape hatches exist and each has a cost. npm overrides, Yarn resolutions, Maven dependency management and Go's replace directive all let you force a version, which works right up until the intermediate package genuinely depended on the old behaviour. Forcing a transitive version without testing the intermediate is a way to convert a security finding into a production incident, so we treat every override as a change that needs its own verification rather than a one line fix.

Lockfiles, and the reproducibility question

If your build resolves versions fresh each time, you do not know what you shipped, which means you cannot answer what you shipped when a CVE lands. Committed lockfiles, verified integrity hashes and a build that fails rather than silently resolving a new version are the baseline. The check we run first on any new codebase is whether two builds of the same commit produce the same dependency set. Often they do not, and that is the finding to fix before any scanning is worth doing.

SBOM: generate it at build time, not afterwards

A software bill of materials is a machine-readable inventory of what went into a build, in CycloneDX or SPDX format. Syft and Trivy will generate one; most build tools now can too. The important detail is when: an SBOM generated from the build itself reflects what actually got compiled and packaged, while one reconstructed later from a manifest reflects what somebody thinks was there.

Store it with the release artifact and keep the history. The payoff arrives on the day a widely used component turns out to be vulnerable and your customers, your auditor or your board all ask the same question within an hour. Teams with queryable SBOMs answer in minutes. Teams without spend the first day of the incident working out what they run.

Provenance and signing

Knowing what is in the artifact is half the question. The other half is whether the artifact came from your build at all. Sigstore and cosign make signing build outputs practical without running your own key infrastructure, in-toto attestations record how the artifact was produced, and the SLSA framework gives you a graded ladder for how much of that you have actually achieved. Most teams we work with start at the bottom of that ladder, and the first two rungs, a scripted build and generated provenance, deliver most of the value.

This connects directly to your build system, which is why supply-chain hardening usually lands as a joint piece of work with pipeline changes. If your CI/CD pipeline rebuilds the artifact between staging and production, signing it is theatre, because the thing you signed is not the thing you shipped.

Typosquatting, dependency confusion and the human layer

Package registries are open by design, and that has been exploited in ways worth knowing about. Typosquatting registers a name one character away from a popular package and waits for a typo. Dependency confusion, published as a research technique in 2021 and widely reproduced since, exploits build tools that check a public registry before a private one, so an attacker publishes a package with your internal name at a higher version number and your build fetches theirs.

Compromise of legitimate packages has also happened repeatedly, through maintainer account takeover and through a maintainer handing a popular package to a stranger who turned out to have a plan. The xz-utils backdoor discovered in 2024 was the sharpest recent example of how patient that kind of attack can be.

The defences are mundane and effective. Scope private packages so an internal name cannot be resolved from a public registry. Pin the registry per scope rather than trusting resolution order. Require review on any new dependency addition, with a check on age, maintainer count and download history, not just licence. Disable install scripts where the ecosystem allows it. And keep the dependency count under some conscious control, because every package added is a maintainer you are trusting.

Authentication and Authorisation Testing, Including IDOR and BOLA

Almost nobody automates this part, and it is where the expensive incidents live. Broken access control sits at the top of the OWASP Top 10 for a reason: it is common, it is easy to exploit, and it is invisible to pattern-matching tools because the vulnerable request is perfectly well formed.

Why scanners are structurally blind here

Consider an endpoint that returns an order by identifier. The code fetches the order and returns it. There is no injection, no unsafe deserialisation, no missing header. The only thing wrong is that it never checked whether the authenticated caller owns that order. A static analyser sees a database read and a response. A dynamic scanner with one session sees a valid 200. Nothing in the request or the code says anything is wrong, because whether it is wrong depends entirely on your business rules.

The API Security Top 10 splits this into distinct failures that are worth separating, because the fixes differ. Broken object level authorisation is the one above: the caller reaches an object they do not own. Broken function level authorisation is when a standard user reaches an administrative operation, usually because the check is in the user interface rather than the API. Broken object property level authorisation is subtler: the caller is allowed the object but should not be able to read or write one of its fields, which is how mass assignment turns a profile update into a privilege escalation by including a role field the front end never sends.

How we actually test it

The method is dull and it works. Build a matrix of roles against resources and operations, drawn from how the product is meant to behave rather than from the code, because deriving expected behaviour from the implementation just re-encodes the bug. Then create real accounts at each role level, capture real object identifiers belonging to each, and drive requests that cross the boundaries: user A's token against user B's identifiers, a standard user against administrative routes, a tenant against another tenant's data.

What you assert matters. A 404 and a 403 are both acceptable outcomes, but silence is not, and a 200 with an empty body is a bug waiting to become a leak. We also check the negative direction, that legitimate access still works, because an authorisation fix that quietly breaks a real user path is how these changes get reverted.

These checks then live in your test suite and run on every merge. That is the point. A one-off audit tells you the state of the system on a Tuesday; a suite of authorisation tests tells you the state of the system forever, and catches the regression when somebody refactors the middleware in nine months.

The authentication layer itself

Separate from authorisation, the identity layer has its own checklist. Whether tokens are actually validated rather than merely decoded, which is a real and recurring bug. Whether the signing algorithm is pinned so a token cannot be presented with the algorithm set to none. Whether expiry is enforced server-side. Whether logout invalidates anything or only clears a cookie. Whether password reset tokens are single use, time limited and unguessable. Whether rate limiting exists on the reset and multi-factor endpoints and not only on login, which is the gap attackers go to first.

Multi-tenant systems deserve their own pass, because tenant isolation is authorisation with a much worse blast radius. The specific thing to test is whether isolation is enforced in one place at the data access layer or reimplemented in every query, since the second pattern fails the moment somebody writes a new query and forgets.

Threat Modelling: The Cheapest Step, Done Too Late

A whiteboard session costs a couple of hours. Finding the same flaw after it has shipped costs a release, a migration and sometimes a disclosure. Yet threat modelling is usually the step teams skip, because it produces no artefact that looks like progress and because the formal versions of it are heavy enough to put anyone off.

The lightweight version is four questions, and they are enough for most teams: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job. Run against a data flow diagram that fits on one page, with the trust boundaries drawn in, that conversation reliably surfaces things no scanner would ever have found. The most common finding in our experience is not an exotic attack. It is a trust boundary that turns out not to exist, an internal service that assumed its callers were trustworthy and is in fact reachable from a path nobody had traced.

STRIDE gives you prompts when the conversation stalls: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege, applied element by element to the diagram. Where privacy obligations are in play, LINDDUN covers the same ground with privacy-specific prompts such as linkability and identifiability, which surfaces different findings entirely. Use them as prompts, not as a form to complete. The moment the output is a spreadsheet nobody reads, the exercise has failed.

Timing is the whole point. Threat model at design time for a new system, when the answer can still be a different architecture. After that, model at the moments when the shape changes: a new integration, a new trust boundary, a new class of data, a change of authentication provider. Rerunning the whole exercise quarterly on a stable system produces the same document and teaches everyone that it is a ritual. The output that we hand over is short: the diagram, the trust boundaries, the ranked list of what could go wrong, and for each item either a mitigation, a test that would catch it, or an explicit decision to accept it. That last category is the one auditors ask about and the one teams most often leave undocumented.

What a Security Testing Engagement Actually Covers

Not every engagement includes all of this, and the order is set by the assessment. Turning on more scanners before the existing output is triaged is the most common way to make things worse while appearing to make progress.

An assessment of what you already have

The first week produces findings about your process, not about your code. What tooling is running, where, and does anything actually block. How many findings exist, how old is the oldest, and who has ever closed one. What the suppression list looks like. Whether the dependency tree resolves reproducibly. Whether authorisation is tested at all. Where secrets currently live and how they got there. Whether a threat model exists for anything.

That produces a short document with a prioritised list, and it is useful on its own. Several engagements have ended there, with the client's own team executing the list, and that is a legitimate outcome.

Tool selection, configuration and tuning

Choosing tools that fit your languages and your budget, configuring them against your frameworks rather than their defaults, writing custom rules for the patterns specific to your codebase, and establishing baselines so the gate is enforceable. Where you already own a commercial tool, we tune that rather than argue for a replacement, because a tuned tool you have already paid for beats an untuned tool you have not.

Pipeline integration at the right stages

Wiring the checks into pull request, merge, release and scheduled runs as described above, with the reporting routed to where your engineers already work. This is a joint piece of work with whoever owns your build system, and it is where most of the practical friction lives.

Authorisation and business logic test suites

The role and resource matrix, the cross-boundary test cases, the multi-tenant isolation checks, and the business flow abuse cases that matter for your product. Written as tests in your repository, in your test framework, running in your pipeline. Not a report.

Dependency and supply-chain hardening

Reproducible resolution, an upgrade policy with automation, SBOM generation attached to releases, registry scoping to close the confusion path, and a review step for new dependencies. Plus the actual work of clearing the backlog of reachable vulnerable components, which is usually the largest single chunk of remediation effort.

Secrets remediation and prevention

History scan with verification, the rotation programme for anything live, pre-commit and push protection, and where practical the architectural change that removes the need for the long-lived credential at all.

Handover that makes us unnecessary

The definition of done is your team running this without us. That means documented triage process with owners and response times, the rule set in version control with comments explaining each custom rule, runbooks for the common finding types, the threat model and its diagram, and a short written record of what we deliberately did not cover so nobody assumes coverage that does not exist.

Manual penetration testing and red team exercises are a separate engagement with a different shape, different people and a different reporting cycle. We scope it separately rather than folding a few days of manual probing into a tooling engagement and calling it a pen test.

Four Situations We Get Called Into

These are archetypes, described from the shape of the problem rather than from any named client. If one reads like your quarter, the diagnosis is the part worth arguing with.

The enterprise deal that arrived with a security questionnaire

A twenty person product company signs its largest customer, and the customer's procurement team sends a two hundred question security questionnaire with a deadline. Nobody at the company has seen one before. Several questions ask about things that genuinely do not exist: a documented vulnerability management process, evidence of testing, an inventory of third-party components.

The work here is sequencing, because everything cannot be built at once and some answers are more expensive to fake than to fix. We map the questions to what actually exists, build the missing pieces with the largest effect first, which are usually dependency scanning with a documented triage process and an SBOM, and write honest answers with remediation dates for the rest. Buyers accept a credible plan far more often than teams expect. What the questionnaire's compliance references require of you specifically is a conversation for your counsel and your auditor, and we build against their reading rather than inventing one.

The scanner that has been red for eighteen months

A mid-sized engineering team turned on the code host's default scanning and never triaged it. There are thousands of open alerts across forty repositories, no owner, and a shared understanding that the alerts are noise. Somebody senior has now asked whether there is anything real in there, and nobody can answer.

We treat the pile as an archaeology problem. Deduplicate across repositories, discard anything in dead code or archived repositories, rank by reachability and by whether the component is on the KEV list, and produce a list of genuine issues that usually turns out to be one or two percent of the total. Then baseline the rest so new code is held to a real standard, and put the actual list into the normal sprint process with owners. The point is not to close everything. It is to make the red mean something again.

The multi-tenant SaaS that has never tested isolation

A platform with tenant separation enforced by a where clause in every query, added by convention rather than by construction. It works, as far as anyone knows, because nobody has ever tried to break it. The team is now onboarding a customer whose security team will try.

We build the isolation test suite: two real tenants, real object identifiers, and systematic cross-tenant requests across every route derived from the API specification. In this pattern the failures are rarely uniform. It is almost always a handful of newer endpoints, a reporting or export path, and something in an admin surface where a support tool takes a tenant identifier as a parameter and trusts it. The durable fix is moving isolation from convention to construction, so a query cannot be written without the tenant scope, and the test suite is what stops it drifting back.

The API that grew without an inventory

A company with a mobile app, a web app and several partner integrations has accumulated three generations of API. Version one was never turned off because one partner still uses it. The OpenAPI specification describes version three only. Nobody is certain what is deployed on the older subdomains.

The first deliverable is not a test at all, it is an inventory: what is listening, what routes it serves, what it authenticates against, and who uses it. That work regularly finds an endpoint that predates the current authentication system entirely. Then the older surfaces get tested and either hardened or scheduled for shutdown with the partners told in advance. This work overlaps heavily with API design and is usually best done with whoever owns those contracts in the room.

What Goes Wrong, and How We Handle It

These are the problems that come up often enough to be worth naming before they happen, rather than after.

The assessment finds something live in week one

A verified credential still working, an unauthenticated administrative endpoint, an old API version with no authentication at all. This changes the plan immediately, and the tuning work waits. We agree the escalation path before starting for exactly this reason, and we do not sit on a live finding until the weekly report.

Remediation is not our decision to make

We can find, prioritise and often fix, but a fix that changes behaviour needs your product judgement. Tightening an authorisation rule may break an integration somebody relies on. Upgrading a major dependency version may require a migration nobody has scoped. We present these as decisions with options and consequences rather than shipping them and finding out.

The finding count goes up before it goes down

Better tuning and better coverage produce more real findings, not fewer, and the graph looks alarming halfway through. We say this at the start and report the number that actually matters, which is the count of genuine open findings above threshold, not raw alerts. Executives who were not warned reasonably conclude that things are getting worse.

Nobody on your side owns triage

The most common cause of an engagement not sticking. If there is no named person receiving findings after we leave, the process decays within a quarter and the scanner is back to being ignored. We ask for that name in week one and design the workload around what one person can realistically carry, because a triage process that assumes a full-time role you do not have is a process that will not survive.

A security fix collides with a release

There is always a week when the fix and the launch want the same code. The way through is agreeing the severity thresholds up front: what ships regardless, what blocks, and who is allowed to accept the risk. Decided in advance, that conversation takes ten minutes. Decided during release week, it takes two days and creates a precedent.

Continuity of the people doing the work

Security engineers get poached, the same as everyone else, and pretending otherwise would be dishonest. What actually protects you is not a promise about tenure, it is how the knowledge is held: no single person is the only one who understands your authorisation rules or your finding backlog, every runbook is reviewed by someone other than whoever wrote it, and the rule sets, scripts and reports live in your repository from week one rather than in someone's head. The commercial side of notice, handover and replacement sits in the agreement, not on this page, and we write it down before work starts rather than letting you find out later.

Engagement Models

Most engagements start as an assessment and become one of the other two, which is deliberate. We would rather quote a build against measurements than against a conversation. If you already know exactly what you need and have the numbers behind it, we can start at the second model.

Frequently Asked Questions About Security Testing in India