When you need it
Your scanners produce thousands of findings, and nobody knows which ones matter. Critical issues sit next to noise in consoles nobody checks, and when a customer asks how fast you fix vulnerabilities, there is no honest answer.
What sets the quote
- Covers the asset types you choose: hosts, container images and registries, Kubernetes, serverless functions and code dependencies.
- Two weeks: one cloud, up to 3 asset types, 20 repositories, 3 owning teams and one ticket system.
- Three weeks: one cloud, all five asset types, up to 50 repositories and 6 owning teams.
- Four to five weeks: 2 or 3 clouds, up to 100 repositories and 12 owning teams.
- Assets are counted with a free read-only inventory query (AWS Resource Explorer, Azure Resource Graph or Google Cloud Asset Inventory) and your repository list. Larger estates are quoted after sizing.
What changes
- Every asset type in scope is scanned, and new repositories, images and hosts are covered by default.
- Findings reach the team that owns the asset as tickets, with a deadline set by severity.
- Agreed triage rules filter out the noise, so teams fix what is actively exploited and exposed first.
- Accepted risks sit in an exception register with an owner and an end date, not in a muted alert.
- A weekly report shows open findings, missed deadlines and the trend for each team.
What you get
- Scanning turned on for each asset type in scope, with new assets covered by default
- Triage rules that rank findings by severity, known exploitation (CISA KEV), exploit likelihood (EPSS), internet exposure and asset criticality
- Fix deadlines by severity, agreed with you and written into a one-page policy
- Ownership map from assets and repositories to owning teams
- Ticket integration with Jira, ServiceNow, Azure Boards or GitHub Issues
- Exception register with an owner, a reason and an end date for each accepted risk
- Weekly report of open findings, missed deadlines and trend, per team
- Runbook and a handover session with the owning teams
What we cover on each cloud
| Asset type | AWS | Azure | Google Cloud |
|---|---|---|---|
| Hosts | Amazon Inspector | Defender for Servers in Microsoft Defender for Cloud | Security Command Center findings for Compute Engine VMs |
| Container images and registries | Amazon Inspector for Amazon ECR | Defender for Containers for Azure Container Registry | Artifact Analysis for Artifact Registry |
| Kubernetes | EKS images through Amazon ECR scans, plus Trivy Operator | AKS through Defender for Containers | GKE images through Artifact Analysis, plus Trivy Operator |
| Serverless | Lambda functions through Amazon Inspector | Azure Functions through repository and registry scans | Cloud Run through Artifact Analysis of its images |
Code dependencies are covered the same way on every cloud: Dependabot or Renovate in your repositories and Trivy in CI. Every scanner and CI action is pinned to a verified version.
Not included
- Fixing the vulnerabilities (your teams do it, or we quote it separately)
- Static code analysis (SAST) and dynamic web scanning (DAST)
- Penetration testing (we can refer you to a certified partner)
- Laptops and desktops (see the Microsoft 365 security baseline)
- Scanner licences and cloud charges, billed by the vendor or your cloud provider
What we need from you
- AWS: AmazonInspector2FullAccess in your security tooling account, which your management account admin sets as the delegated administrator for Amazon Inspector.
- Azure: Security Admin at the management group in scope, to turn on Defender for Cloud plans.
- Google Cloud: Security Center Admin at organisation level, and Service Usage Admin on the projects that need Artifact Analysis.
- Code and tickets: the GitHub security manager role (or the Azure DevOps or GitLab equivalent) and an integration account in your ticket system.
- A contact in each owning team, and a 60-minute session with your security and engineering leads to agree triage rules and deadlines.
How it works
Free 30-minute call, then the sizing query and a written fixed quote.
Map assets and repositories to owning teams, and agree triage rules, fix deadlines and the exception process.
Turn on scanning for each asset type and connect it to your ticket system.
Run the first weekly reports with your teams, tune the rules and hand over.
At a glance
- Duration
- 2–5 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related services
Zero Trust assessment
In 1–2 weeks, a review of identity for people, devices and workloads, cloud guardrails and CI/CD, with every control checked as declared, refused and in effect, ending in a maturity rating per area and a roadmap.
Threat modelling workshop
A STRIDE threat model of one system or major feature, built with your team in two half-day sessions over one to two weeks, with a data-flow diagram, trust boundaries and prioritised mitigations in your backlog.
OS hardening baseline
Linux and Windows Server hardened to CIS Benchmarks Level 1 in two to six weeks, built as code with golden images, enforced settings, drift checks and compliance evidence for every host.