On this page
What a DevOps security audit covers
Security problems in modern applications often sit outside the code itself: an outdated dependency with a known vulnerability, a cloud storage bucket that is publicly readable, an API key in the Git history, a CI workflow with more permissions than it needs, or an admin panel reachable from anywhere. A security audit looks across all of these areas and tells you which ones matter.
The output is practical: a list of findings, each explained in terms of the actual risk in your context, ranked so the most important work happens first.
Who needs one
- SaaS companies preparing for a customer’s security questionnaire or due diligence.
- Businesses that inherited an application or infrastructure from another team.
- E-commerce stores handling customer accounts and payment flows.
- Clinics, coaching platforms and others that hold personal data.
- Teams that have grown quickly and never paused to check the basics.
An audit is also useful before a significant change, such as a major launch, a migration to a new provider or bringing on a large customer. Finding issues beforehand is far less disruptive than discovering them afterwards.
What we review
- Dependencies: known vulnerabilities in libraries, base images and runtimes.
- Secrets: keys and passwords in code, Git history, CI logs or shared documents.
- Access and permissions: cloud accounts, servers, CI tokens and database users.
- Exposed surfaces: open ports, admin panels, storage buckets and forgotten subdomains.
- Configuration: TLS, security headers, CORS, debug modes and default credentials.
- Pipelines: CI/CD permissions, protected branches and third-party actions.
- Backups and recovery: whether backups exist, are protected and can be restored.
We handle any access you grant carefully: read-only where possible, limited to what the scope needs, and removed at the end of the engagement. Findings containing sensitive details are shared only with the people you nominate.
How the audit works
- Agree scope and access: which repositories, servers, cloud accounts and environments.
- Run automated scans for dependencies, secrets, open ports and configuration.
- Review results manually to remove false positives and add context.
- Examine permissions, pipelines and architecture where automated tools cannot judge risk.
- Deliver a prioritised report and walk through it with your team.
- Optionally implement the fixes and re-check afterwards.
If we find something urgent during the audit, such as an exposed secret or a publicly reachable database, we tell you straight away rather than waiting for the final report, so it can be closed immediately.
Tools we use
Depending on your stack, we use dependency scanners such as npm audit, pip-audit and GitHub’s dependency alerts, container image scanners, secret scanners that search Git history, port and TLS scanners, and the security features of AWS, Google Cloud and Azure. Automated tools find candidates; the value is in the manual review that decides which findings actually matter for your setup.
Scans run with care on production systems, at agreed times and with gentle settings, so the audit itself never disrupts your service.
How findings are prioritised
| Priority | Meaning | Example |
|---|---|---|
| Fix now | Easily exploitable and exposed | Live API key in a public repository; database open to the internet |
| Fix soon | Real risk, but harder to exploit or less exposed | Outdated dependency with a known issue in a reachable feature |
| Plan | Good practice that reduces future risk | Broad CI permissions, missing security headers |
| Note | Low risk in your context | Scanner warning about a component you do not use |
Every finding includes what it is, why it matters for you, and a concrete fix.
What affects timeline and cost
A single application on one server is a focused review. Scope grows with the number of repositories, services, cloud accounts and environments, and with how much history there is to search. Implementing fixes is scoped separately once you have seen the findings and decided what to act on.
Audits are most useful when repeated. A lighter follow-up review after fixes are applied confirms they worked, and periodic re-checks catch new dependencies and configuration drift.
Common mistakes
- Treating every scanner warning as equally urgent and fixing none of them.
- Removing a leaked secret from code without rotating it.
- Checking the application but ignoring the CI pipeline and cloud account permissions.
- Auditing once and never again.
Related: Server Security Hardening, Environment Configuration and our Cyber Security services. See all DevOps & Deployment services, the DevOps guide, or contact us.
Frequently asked questions
Is this a penetration test?
No. It is a review of configuration, dependencies, secrets and permissions. It often finds the issues attackers exploit most, but it does not replace active penetration testing where that is required.
What access do you need?
Read access to the relevant repositories and cloud accounts, and limited server access. We agree exactly what before starting.
Can you fix what you find?
Yes. Many clients ask us to implement the fixes after reviewing the report, followed by a re-check.
Will the report help with a customer security questionnaire?
It helps you answer accurately, because it shows what is actually configured and what has been fixed.
How often should we repeat the audit?
After major changes and at regular intervals. Dependencies and configuration change constantly, so findings go out of date.
Talk to us about security auditing
A review of dependencies, permissions and exposed surfaces, delivered with a fix list.