The security lead opens the sprint review with a number. Four thousand one hundred and eighty-two open findings across the estate. Last quarter it was three thousand six hundred. The engineering director does not argue with the number. He asks which of them his team is being asked to fix this sprint, and why those.
Nobody in the room can answer that from the data they have. The static analysis tool has its own severity scale. The dependency scanner uses CVSS. The container scan reports base image CVEs that have been open since the image was first pulled. The cloud posture tool belongs to the platform team and reports into a different dashboard. The secrets scanner flagged eleven credentials last month, all rotated, none removed from git history.
Somebody eventually says what everyone is thinking. Of the four thousand, maybe forty genuinely matter this quarter. Identifying those forty would take two engineers a week, and by the time they finished another two hundred would have arrived.
This is the state of application security in a great many organisations across India, Sri Lanka, Bangladesh, Singapore and the Gulf. Not a coverage gap. An accuracy and ownership gap, getting worse in proportion to how many scanners get added.
Nobody was ever given the decision
The secure development lifecycle document has an answer for all of this. Code is scanned before merge, dependencies are checked, images are scanned before deployment, infrastructure templates are validated and cloud configuration is monitored continuously. Every statement is true. The tooling exists, the pipelines run, the reports generate.
What the document does not describe is who decides what gets fixed, in what order, on whose sprint capacity. That was never assigned, because when the programme was designed it did not look like a decision. It looked like arithmetic: find the vulnerabilities, rank by severity, fix from the top. The tools would produce the list and the list would be the plan.
It stopped working around the time the third scanner came online. Each tool ranks risk within its own world view and cannot compare a static analysis finding against a container CVE against an over-permissive IAM role. There is no shared denominator, so seven partial plans arrive that cannot be merged, and merging them becomes a human job nobody was hired to do.
The security team absorbs it by default. In most organisations across our region that team is two to five people who also run questionnaire responses, the SOC 2 or ISO 27001 evidence cycle, vendor risk reviews and the incident process. Triage becomes what gets done in the last three days before an audit, in a spreadsheet, from scratch, again.
Meanwhile engineering has made its own judgement. Developers are not refusing to fix security issues. They are refusing to spend a sprint on findings that turned out, the last three times, to be irrelevant to their service. That is a rational response to a low-precision signal, and it is the most damaging thing that can happen to a security programme, because once credibility is gone even genuine findings arrive pre-discounted. The org chart says security assesses and engineering remediates. Reality says security produces volume and engineering produces judgement, and the two never meet in one place.
Where application security actually breaks
The failure is rarely in detection. It is in everything that happens between detection and a merged fix.
- Seven scanners, seven severity scales, seven logins
Count the tools honestly. Static analysis. Open-source dependency scanning. Secrets detection. Container image scanning. Infrastructure-as-code checks. Cloud posture monitoring. Dynamic testing against staging. That is seven, before anything for API security, licence compliance or runtime.
Each was bought to close a specific gap and each closed it. Each also arrived with a separate dashboard, a separate notion of critical, a separate integration into source control, a separate renewal date and a separate set of user accounts. When a developer asks whether they are clean to ship, answering that honestly requires checking seven places.
The consequence is that nobody checks all seven. People check the one that blocks the build and ignore the rest until an audit or an incident forces it.
- A critical CVE in a library nothing ever calls
A dependency scanner flags a CVSS 9.8 in a transitive package. It is genuinely severe in that package. The ticket goes to the team that owns the service, who discover that the vulnerable function lives in a code path their application never touches, in a package pulled in by a dependency of a dependency, used only for a feature they do not enable.
Upgrading means a major version bump that breaks two interfaces and needs regression testing across three services. Four days of work, for a vulnerability that in their deployment is not reachable.
They push back. Security cannot easily prove them wrong, because proving it requires call-graph analysis nobody has time to do by hand. The finding is deferred with a note, reappears next quarter, and accumulates alongside a few hundred others in the same condition. The backlog stops being a list of risks and becomes a list of arguments nobody wants to have twice.
- The dashboard developers stopped opening
Ask when a developer on your team last logged into the security dashboard voluntarily. Not because a build failed or someone assigned them a ticket. Voluntarily, to check their own service.
In most organisations the answer is months, and the reason is precise. The last three tickets out of that dashboard were noise: a hardcoded string in a test fixture flagged as a secret, a dependency finding for a dev-only package, a static analysis hit on code already behind an authorisation check the scanner could not see.
Rebuilding that trust is far harder than losing it, and while it is gone every security request costs political capital.
- Secrets that were rotated but never removed
A developer commits an API key. The secrets scanner catches it, an alert fires, the key is rotated within the hour. Fast response, incident closed.
Except the commit is still in git history. It is in every clone on every laptop, every fork, the CI cache and whatever mirror the build system keeps. If that repository is ever exposed, or a contractor’s machine is compromised, the key is right there in the log. Rotation handled the live credential and did nothing about the artefact.
Now multiply by three years of commits, several dozen repositories and staff turnover. Most teams have no idea how many secrets sit in their history, whether any are still valid, or which system each one opens. The scanner watching new commits was never pointed at the past.
- Container images that arrive with hundreds of inherited CVEs
The application team writes a Dockerfile starting from a standard base image. The scan comes back with three hundred CVEs. Perhaps two are in the application’s own dependencies. The rest are in operating system packages, system libraries and runtimes inherited from the base image.
The team cannot patch those. They did not choose most of them, they cannot upgrade individual OS packages without rebuilding an image they do not own, and many of the CVEs are in components their container never executes. The only real lever is changing base images, which is a platform decision.
So the report gets filed. It shows three hundred criticals against a service the team considers well maintained, and everyone learns to ignore container scan output, including on the day it reports something real.
- Cloud misconfiguration that belongs to a different team
The posture tool flags a storage bucket with over-broad access and a database without encryption at rest. Both are real. Neither belongs to the application team the finding was routed to.
The bucket was created by data engineering for an analytics pipeline. The database was provisioned by the platform team through a Terraform module since forked three times. Fixing either requires knowing which team owns the resource, which module produced it, whether the module was fixed at source or only in one deployment, and whether the change breaks a downstream job nobody documented.
The finding sits in a queue while ownership is established over Slack. Cloud posture findings tend to have the longest time-to-close in the estate, not because they are technically hard but because they cross organisational boundaries that scanners do not model.
- The audit request that needs evidence from all seven tools
A customer in Singapore or the Gulf sends a security questionnaire. Or the ISO 27001 surveillance audit comes round, the SOC 2 observation window opens, or a bank’s third-party risk team asks for your vulnerability management evidence.
They want the same things. Proof that you scan code, dependencies, containers and infrastructure, that findings are triaged against a documented policy and remediated within stated timeframes, and that the process ran continuously across the whole period rather than in the fortnight before the audit.
Producing that means exporting from seven tools in seven formats, reconciling them into one narrative, explaining why counts differ, and assembling remediation timelines by hand from ticket histories. It takes weeks of senior time, happens two or three times a year, and produces nothing durable.
For a fintech in Colombo or Dhaka chasing enterprise deals, or an IT services firm in Bangalore or Dubai answering client due diligence for the fourth time this quarter, this is a standing tax on the same small team that is supposed to be doing the triage.
Why buying an eighth tool makes it worse
The instinct when the list is unmanageable is to buy something that manages lists: a vulnerability management platform, a risk aggregator, a correlation layer to sit above the seven and tell you what matters.
It rarely works.
First, the integration tax. The aggregator ingests from every scanner: seven connectors, seven authentication configurations, seven field mappings and seven things that break quietly when a vendor changes an API. Somebody owns that plumbing, and it is the engineer who was already the bottleneck.
Second, aggregation does not create accuracy. If the dependency scanner cannot tell you whether a vulnerable function is reachable, a tool consuming its output cannot tell you either. Normalising seven unreliable severity scores into one is a presentation improvement, not a risk improvement. You get a cleaner dashboard showing the same four thousand findings.
Third, licence and renewal sprawl. Eight products, eight commercial relationships, eight renewals, eight supplier reviews, eight sets of user provisioning. For an organisation with three security people, administering the stack starts competing with doing security.
Fourth, and most damaging, it widens the gap it was meant to close. The aggregation layer lives with security while developers still work in their IDE, their pull requests and their ticket board. A management layer on the security side improves security’s view and does nothing for engineering’s, so the distance between what security reports and what engineering will fix grows rather than shrinks.
Hiring for it has the same shape. A triage analyst is a person paid to do by hand what the tooling should have done by construction, and in most of our markets that person is hard to hire and harder to keep.
The honest conclusion is uncomfortable. The problem is not that you lack a layer above the scanners. It is that you have seven scanners.
How Aikido Security approaches this differently
Aikido Security is built on the opposite assumption to the tool-per-problem model: that code, dependencies, secrets, containers, infrastructure templates, cloud configuration and runtime are one attack surface and belong in one system, with one view of risk and one place a developer finds out what to fix. That is an architectural position, not a packaging exercise, and consolidation matters less than what it enables: triage that sees the whole picture at once.
- One platform across the surface
Aikido organises its coverage into four areas. Aikido Code covers static analysis (SAST), dependency scanning (SCA), secrets detection, supply-chain malware detection, licence and SBOM management and code quality. Aikido Cloud covers cloud misconfiguration and posture management (CSPM), infrastructure-as-code scanning, Kubernetes scanning, container image scanning, virtual machines, hardened images and data security posture. Aikido Attack covers dynamic testing (DAST), API scanning, attack surface monitoring and pentesting. Aikido Protect covers runtime, including Zen, the in-app firewall.
The point is that a container finding, the dependency finding it derives from and the runtime exposure of the service that ships it sit in one system, evaluated against each other, rather than in three tools that have never heard of one another.
- Triage as the core function, not a filter bolted on
The capability that changes the arithmetic is reachability analysis. Rather than reporting every CVE in your dependency tree, Aikido evaluates whether the vulnerable code is actually reachable from your application and filters unreachable findings out automatically. The CVSS 9.8 in the transitive package nothing calls stops being a ticket and an argument.
Alongside it sit automatic deduplication, so one underlying issue across many services is one item, and context-aware severity, so an identical misconfiguration ranks differently in production than in staging. Auto-triage learns context from your environment and documentation, and findings can be silenced intelligently rather than re-triaged by hand each sprint. The output is what engineering asked for at the start of this post: a short list with a defensible reason for each item on it.
- Fixes that arrive as pull requests, not tickets
AI AutoFix generates a remediation and opens a pull request rather than filing a ticket for someone to interpret. It covers dependency upgrades, SAST and IaC findings and container issues, with breaking-change and upgrade-impact analysis so a fix does not arrive as an unreviewed surprise. Behaviour is configurable: signed commits, default reviewers, auto-merge rules and custom context for how fixes should be written in your codebase. This inverts the workflow that broke developer trust. The finding arrives as a diff to review, in the tool the developer already has open.
- Secrets, containers and cloud handled at the right layer
For secrets, Aikido combines pattern matching, entropy analysis and validation logic, can optionally scan full git history rather than only current code, and uses live secret detection to check whether an exposed credential is still active, adjusting severity accordingly. The rotated-but-never-removed key is classified honestly instead of counted as an unresolved critical forever.
For containers, scanning is agentless, pulling image layers from your registry or through CI across the public and private registry platforms teams actually use. Findings are prioritised by reachability rather than raw CVE count, and hardened images with AutoFix for containers give the base-image problem a lever the application team can pull.
For cloud, CSPM is agentless and read-only through provider APIs across AWS, Azure and GCP, covering IAM, storage, networking, out-of-support runtimes and managed Kubernetes, with severity adjusted by environment.
- Supply chain and runtime
Aikido Intel maintains a live feed of malicious package intelligence across npm, PyPI, NuGet, Maven, RubyGems and VS Code extensions, feeding malware detection in dependencies and containers. Safe Chain hooks into npm, yarn and pnpm to block malicious dependencies at install time.
Zen, the in-app firewall, is an open-source embedded library rather than an external agent, supporting Node.js, Python, PHP, Java, .NET, Ruby and Go. It blocks injection-class attacks at runtime and adds user-aware rate limiting and blocking of bots, Tor and known threat actors. Where an upgrade is genuinely not feasible this quarter, runtime blocking is a real mitigation rather than an accepted risk.
- Evidence that assembles itself
Aikido maps its scanning to the technical controls behind ISO 27001:2022, SOC 2 Type 2, PCI DSS, HIPAA, DORA, NIS2 and CIS Controls v8, and generates evidence continuously rather than on demand. It also syncs with the major compliance automation platforms, and SBOM generation is native.
For teams working through customer questionnaires alongside SOC 2 or ISO 27001, and regional expectations under India’s DPDP Act, Sri Lanka’s and Singapore’s PDPAs, the UAE PDPL, Saudi PDPL and NCA controls or sector guidance from RBI and SAMA, evidence becomes a by-product of the process rather than a project each cycle.
- Where it meets developers
Integrations cover the mainstream git hosting platforms and CI/CD systems, IDEs, task managers, messaging tools, cloud accounts and container registries. Pull request comments and IDE feedback put findings where work already happens.
EGUARDIAN distributes Aikido Security across its territories and works with channel partners on evaluation, deployment and the triage-policy design that decides whether consolidation actually reduces workload.
What this looks like in practice
Take the team from the opening scene: four thousand findings, three security staff, an ISO 27001 surveillance audit in nine weeks.
- Connect source control, container registries and cloud accounts. Scanning is agentless, so nothing is installed into applications.
- Run the baseline across repositories, images, IaC templates and cloud configuration in one platform, producing one inventory.
- Apply reachability analysis and deduplication. Unreachable dependency findings drop out, repeated findings collapse into single items, and the list becomes readable.
- Run secrets detection over full git history with live validation, separating still-active credentials from artefacts of rotated keys.
- Set context-aware severity so production ranks above staging, and define triage and SLA policy once rather than per tool.
- Turn on AutoFix for dependency, IaC and container findings, with default reviewers and breaking-change analysis.
- Route what remains into Jira and pull request comments, and deploy Zen where an upgrade is genuinely blocked.
- Connect the compliance integration so ISO 27001 and SOC 2 evidence accumulates ahead of the audit.
The four thousand does not become forty by magic. It becomes a ranked list where each item has a stated reason for being there, the mechanical fixes arrive as pull requests, and the sprint review argument is about sequencing rather than legitimacy.
Challenge and response
| Challenge | How Aikido addresses it |
|---|---|
| Seven scanners, seven severity scales, seven dashboards | One platform spanning code, dependencies, secrets, containers, IaC, cloud, DAST and runtime |
| Critical CVEs in libraries the application never calls | Reachability analysis filters unreachable findings; deduplication and context-aware severity rank what remains |
| Developers who stopped trusting the dashboard | AI AutoFix opens pull requests with breaking-change analysis; findings surface in IDE, PR comments and Jira |
| Secrets rotated but still live in git history | Optional full-history scanning with live secret validation, so severity reflects whether a credential still works |
| Base-image CVEs the application team cannot patch | Agentless registry and CI image scanning, reachability-based prioritisation, plus hardened images with AutoFix |
| Cloud misconfiguration owned by a different team | Agentless, read-only CSPM across AWS, Azure and GCP, in the same queue as code findings |
| Audit evidence spread across every tool | Continuous mapping to ISO 27001, SOC 2, PCI DSS, DORA and CIS controls, native SBOM, and GRC platform sync |
Who benefits most
Software product companies and SaaS firms selling to enterprise or overseas buyers, where every deal brings a security questionnaire and engineering vastly outnumbers security.
Fintechs, digital banks and payment providers across South Asia and the Gulf, where evidence of continuous vulnerability management is not optional and three people handle scanning, triage and audit.
IT services and BPO organisations in Bangalore, Colombo, Dhaka, Singapore and Dubai running many client codebases at once, needing consistent posture and per-client evidence without a separate stack per engagement.
Platform and DevOps teams who inherited the security tooling by accident and now maintain scanner integrations instead of shipping infrastructure.
The problem was never the finding count
Application security has been measured by coverage: how many repositories scanned, how many images, how many cloud accounts. Those numbers are easy to grow and they look like progress.
The number that matters is harder. What proportion of what you report actually gets fixed, and how quickly. That is credibility, not coverage. An organisation that surfaces forty findings and fixes thirty-eight is in a far better position than one that surfaces four thousand and fixes ninety.
Getting there means accepting that precision is a platform property, not something a person supplies by working harder. Reachability, deduplication, context and a fix that lands as a pull request are things the tooling either does by construction or does not do at all. No amount of triage effort recovers a signal the scanner never had.
For teams working with small headcount against growing customer and regulatory expectations, that shift is the difference between a security programme engineering respects and a backlog everyone has learned to ignore.
Talk to our experts at EGUARDIAN. If your application security programme is producing more findings than your engineering team can credibly act on, let us go through your stack, your constraints and what a consolidated, properly triaged setup could look like for your organisation. Reach out to us at hello@eguardian.com.
