DevSecOps security services
DevSecOps means building security checks into the pipeline that turns your code into running software, and reviewing that pipeline the way an attacker would: who can change it, which secrets it holds and what it is trusted to deploy. BERRY9 delivers DevSecOps services from Hyderabad for software teams across India, and every engagement is scoped in writing before it starts.
- Focus
- Pipeline trust, secrets and checks
- Covers
- Commit to runtime
- Pairs with
- Code review and cloud review
- Starts from
- INR 27,000 + 18% GST
Last reviewed
Illustrative Where checks can sit in one delivery pipeline
Commit
Protected branches, required review and a scan for keys pushed by mistake.
Dependencies
Each outside package compared against published vulnerabilities and an approved list.
Build
A runner with only the access this job needs, and output that gets signed.
Templates and images
Cloud templates and container images checked before anything is created.
Deploy
Only signed, approved builds move on, using credentials that expire quickly.
Runtime
Logs and alerts flag any change made outside the pipeline.
Example pipeline, not a client's setup.
01 / What it is
What DevSecOps services cover, and who needs them
DevSecOps puts security inside the delivery process instead of at its end, and it treats the pipeline as something to protect as well as a place to run checks.
DevSecOps is the habit of treating security as part of the same flow that plans, writes, builds and ships software, rather than as a gate someone else opens at the end. The name joins development, security and operations, and the idea is practical: when a check runs automatically every time code changes, a mistake is caught while the person who made it still remembers why, and fixing it costs minutes instead of a release.
There is a second half that teams often miss. The pipeline itself is a valuable target. It holds keys that can reach production, it runs code written by many contributors and pulled from outside sources, and every server it deploys to accepts whatever it produces without question. An attacker who can quietly alter one build step does not need to break into your application; your own release process will deliver their change for them. A DevSecOps engagement therefore asks two questions: are the right checks in the pipeline, and is the pipeline itself hard to abuse?
Teams that usually look for this work:
Teams that release often
Weekly or daily releases leave no room for a long manual review before each one. Automated checks carry that load between deeper tests.
Teams moving to infrastructure as code
When servers, networks and permissions are defined in templates, a single wrong line can open something to the internet in every environment at once.
Teams facing customer or auditor questions
Security questionnaires and audits increasingly ask how code is reviewed, how releases are approved and who can change production.
Teams growing past a few engineers
Pipelines built quickly by one person tend to give everyone broad access. As the team grows, that access needs owners and limits.
What a BERRY9 engagement covers. BERRY9 reviews the security of your pipeline and recommends changes, and your team makes them.
02 / Shift left
Shift-left security across a secure SDLC
Shifting left means doing each security activity at the earliest phase where it works. The table shows what that looks like from planning through to operation.
| Phase | Security activity | What it saves later |
|---|---|---|
| Plan | Security requirements and abuse cases written next to the feature requirements | Rework when a feature turns out to need access controls nobody designed |
| Design | Threat modeling of new components, data flows and trust boundaries | Architectural flaws that no later scan can detect |
| Code | An agreed secure coding standard, peer review and checks before a commit is accepted | Whole classes of bug repeated across many files |
| Build | Automated analysis of source and of third-party packages on every change | Known weaknesses shipped because nobody looked |
| Test | Testing of a running build, and a penetration test before significant releases | Logic and authorization flaws that only appear when the system runs |
| Release | Signed artifacts, recorded approvals and a separation between who writes and who deploys | Untraceable changes reaching production |
| Operate | Monitoring, patching and lessons from incidents fed back into planning | The same failure happening twice |
Moving checks earlier does not remove the need for later ones. Automated checks are good at known patterns and poor at judgment. Broken business logic, a missing authorization step or a chain of small weaknesses still needs a person who thinks like an attacker, which is why a mature program keeps both.
Many teams look for secure SDLC consulting because a customer or a standard asks how they build software, not only whether it was tested. Public frameworks describe the same ground: NIST's Secure Software Development Framework (SP 800-218) groups the practices into preparing the organization, protecting the software, producing well-secured software and responding to vulnerabilities, and ISO/IEC 27001:2022 lists a secure development life cycle among its Annex A controls (control 8.25). Our ISO 27001 testing page explains how technical testing supports that kind of evidence. Where a pipeline review finds that a gap actually starts earlier, for example that no one models threats before a new service is designed, the recommendations say so plainly.
03 / Pipeline checks
Where security checks sit in a CI/CD pipeline
Automated checks can run at eight points between a commit and live software. Each one sees part of the picture, and each one has a blind spot worth knowing.
Show details for Where security checks sit in a CI/CD pipeline
| Stage | What the check looks for | What it cannot tell you |
|---|---|---|
| Source code | Unsafe patterns in your own code, such as string-built database queries or unchecked file paths | Whether a feature should exist at all, or whether its access rules match the business |
| Dependencies | Open-source packages with published vulnerabilities, unexpected licenses or abandoned maintainers | Whether the vulnerable part of a package is actually reachable from your code |
| Build | That the build runs from a reviewed definition, on a clean runner, and produces a recorded, signed output | Weaknesses in the code being built |
| Secrets | Passwords, tokens and private keys committed to the repository or printed in job logs | Secrets already copied elsewhere before the check was added |
| Infrastructure as code | Templates that would create public storage, open network rules or permissions broader than needed | Changes made by hand in the cloud console after deployment |
| Container images | Outdated base images, vulnerable system packages, images that run as the administrator account | How the running container is exposed on the network |
| Deployment | That only approved, signed builds reach each environment, through a controlled identity | Problems in the environment that receives the build |
| Runtime | Configuration drift, unexpected processes and alerts from the live system | Flaws that no one has yet tried to exploit |
The order matters less than the tuning. A check that fails every build for reasons nobody understands is soon switched off, and a switched-off check protects no one. A sensible rollout starts each new check in a mode that reports without blocking, clears the existing backlog or records it as accepted, and only then lets high-confidence results stop a build. Lower-confidence results go to a list a person reviews, so developers learn to trust the signal instead of working around it.
Each check also needs an owner. Someone decides which results block, which are accepted for now and who fixes the rest, and that decision is written down where the next engineer can find it. Without that, a pipeline collects warnings the way an inbox collects unread mail.
04 / Attacker's view
CI/CD pipeline security review from an attacker's view
The pipeline can deploy to production, so whoever controls it controls what you ship. A review tests how far that control reaches and who could take it.
Show details for CI/CD pipeline security review from an attacker's view
A pipeline security review spends less time on what the scanners report and more on how the delivery system could be turned against you. The questions are about trust: who and what the pipeline believes, and what it lets them do.
- Who can change the pipeline definition? If any developer can edit the file that tells the pipeline what to run, every developer account, and every stolen developer password, can change what reaches production.
- What runs on outside contributions? Jobs triggered by pull requests from forks or unreviewed branches should not see production secrets or deploy anything.
- Where do the secrets live? Keys kept as plain CI variables, shared across every project, or echoed into build logs are visible to far more people than intended.
- How much can a build runner reach? A runner that keeps files between jobs, runs with administrator rights or sits on the same network as production gives one compromised job a path into everything else.
- Are outside build steps pinned? Shared steps and plugins pulled by a moving name can change under you; pinning them to a reviewed version keeps someone else's update out of your release.
- Is the output signed and checked? If nothing proves an artifact came from your pipeline, anyone with write access to the registry can replace it, and production will deploy the substitute.
- Can branch protection be bypassed? Required reviews mean little if administrators are exempt, if the rules apply to only one branch, or if a single person can approve their own change.
- How long do deployment credentials last? Long-lived keys copied into pipeline settings years ago are a standing risk; short-lived credentials issued per job expire before they can be reused.
Illustrative Findings of the kind a pipeline review records:
| Finding | What happens | Severity | What your platform team gets |
|---|---|---|---|
| Production keys visible to every pipeline job | Any job, including one started from an unreviewed branch, could read the key that deploys to production. | Critical | Secrets scoped to the deploy job and protected branches only, and the exposed key rotated. |
| Developers can edit the pipeline definition without review | A single account could add a step that alters the release, with no second person seeing it. | High | Pipeline files placed under the same required review as production code, with named owners. |
| Shared build runner keeps files between jobs | One project's job could leave something behind that a later job, from another project, picks up. | High | Fresh, isolated runners per job, or at least per project, with no standing access to production networks. |
| Artifacts are not signed | Nothing at deploy time shows that the image or package came from your pipeline rather than from someone with registry access. | Medium | Signing at build time and a signature check before deployment, rolled out in report-only mode first. |
Severity depends on the setup. An unsigned artifact is a modest risk where registry access is tightly held, and a serious one where many people and systems can write to it. Each finding in a real report is scored with CVSS 3.1 and explained against your own environment.
05 / Method
How a pipeline security review runs
The review follows our usual five phases, applied to a delivery system rather than an application: agree the rules, map the path, review it, confirm what matters and report.
Show details for How a pipeline security review runs
Scope and rules of engagement
Repositories, pipelines, runners, registries and environments in scope are listed in a signed document, along with the accounts used for the review and the jobs it may or may not trigger.
Map the delivery path
From commit to production, we trace every stage, the identity each one runs as, the secrets it can read and the systems it can reach.
Review trust and access
Pipeline definitions, branch rules, runner setup, secret storage, artifact handling and deployment credentials are checked against the attacker's questions.
Confirm what matters
Where a weakness can be shown safely, it is confirmed with a proof of concept agreed with your team beforehand; where showing it would touch production, the evidence is the configuration itself.
Report and walk through
Findings are written up, ranked and explained to the engineers who will fix them, with the order in which to tackle them.
The review is read-mostly. Most of the evidence comes from definitions, settings and logs that can be examined without running anything new, and any job we do run is agreed in the rules of engagement first. Our general approach to every engagement is set out in the VAPT methodology.
Platforms we review. The platforms in scope are agreed at scoping.
How long it takes. The number of repositories and pipelines, and how alike they are, drives the length far more than the size of the codebase does. The length of the review is written into the proposal once the scope is clear.
06 / Engagement
One-time pipeline review or ongoing DevSecOps engagement
Some teams want a single, thorough look at where they stand. Others want help across months of change. The two answer different questions.
Show details for One-time pipeline review or ongoing DevSecOps engagement
| Question | One-time review | Ongoing engagement |
|---|---|---|
| What it answers | How exposed is our delivery system today, and what should we fix first? | Are the fixes holding, and are new pipelines and services built the same way? |
| When it fits | Before an audit or a large customer review, after an incident, or as a first look | When the platform changes often and the team wants a second pair of eyes over time |
| What you receive | A report, a ranked remediation list and a walkthrough | Repeated reviews of new or changed pipelines |
| Who changes the pipeline | Your team, working from the recommendations | Varies: some arrangements include hands-on changes, others advice only |
| How progress is seen | A retest of the fixed findings, as set out under Price | Fewer recurring findings, and checks that keep running without being disabled |
A one-time review is the natural place to start. It gives a clear picture of where the delivery system stands and a list your team can work through on its own. Many teams need nothing more for a while: they fix the urgent items, add the first checks in report-only mode and come back when the platform has changed enough to justify another look.
An ongoing arrangement makes sense when the pipeline is a moving target, for example during a migration to a new cloud account structure or while several teams are building their own deployment paths. Then the value lies in reviewing each change before it settles into habit.
Who makes the changes. Your team makes the changes, working from BERRY9's recommendations.
Ongoing support. BERRY9 delivers a pipeline security review; ongoing DevSecOps support is not part of this service.
07 / Related work
DevSecOps alongside code review, cloud, API and web testing
A pipeline review checks how software is built and shipped. It is most useful next to tests of the code, the cloud and the running application.
Show details for DevSecOps alongside code review, cloud, API and web testing
Source code review
Pipeline checks catch known patterns on every change. A manual code review reads the logic itself and finds what the automated stage was never told to look for.
Cloud security assessment
The pipeline deploys into cloud accounts. The cloud review checks what those accounts already allow, including changes made by hand that no template records.
API security testing
Authorization flaws in an API pass every automated check because the code is valid. Testing the running API is how they are found.
Web application testing
A penetration test of the live application shows what an outside attacker sees, which is the final proof that the earlier checks are doing their job.
Training for your teams
Platform and development teams who understand why a check exists keep it running. Hands-on training builds that understanding.
A useful pairing for a team that releases often is a pipeline review together with a source code review of the most sensitive service, followed by a test of the running application before a major release. Each one covers ground the others cannot. The full list of what we test is on the offensive security services page.
08 / What you receive
What you receive, and what we need from you
The deliverables are the same reports every BERRY9 engagement produces, written for the people who run your delivery platform.
Show details for What you receive, and what we need from you
- An executive report that states how exposed the delivery process is and which changes matter most, in terms a leadership team can act on.
- An engineering report for the platform team, with each finding, the evidence behind it, a CVSS 3.1 score and the recommended fix.
- Proof of concept per finding where it could be shown safely, or the exact configuration that creates the weakness where it could not.
- A remediation matrix that ranks every fix, from rotating an exposed key to restructuring runner access, so owners and dates can be set.
What we need from you
- Read access to the repositories and pipeline definitions in scope
- A view of pipeline settings, secret storage and runner configuration
- A list of environments and how each one receives deployments
- Time with a platform engineer who knows why things are set up as they are
- Your rules on which jobs we may run, and where
Read access is usually enough. We do not need to know the value of any secret to report that it is exposed; the setting that exposes it is the evidence. Where a check needs a job to run, it runs on a branch or a project agreed for the purpose.
The layout of our findings is shown in the sample VAPT report. We work from Hyderabad, our only office, and pipeline reviews are delivered remotely through the access you grant.
09 / Price
What DevSecOps services cost
A DevSecOps pipeline review starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. The starting figure suits one service with a single deployment path. Larger estates, with more pipelines and environments, are priced to match.
DevSecOps pipeline review
Starts fromINR 27,000 + 18% GST
The final price is set in a written proposal after scoping, once repositories, pipelines and environments are known.
Request a scoping call- Number of pipelines. A single service with one deployment path is a small review; dozens of repositories with their own definitions take longer, unless they share common templates.
- Environments. Each extra environment, region or cloud account the pipeline deploys to adds identities and credentials to trace.
- Runner setup. Hosted runners are quicker to review than self-managed fleets on your own network.
- Infrastructure templates and images. Reviewing the templates and container images themselves, not only the pipeline that handles them, adds scope.
- Platforms in scope. Each separate CI/CD platform has its own settings and permissions to review.
To see how this sits beside the price of our other tests, read what VAPT costs in India.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
DevSecOps services by city
10 / Inquiry
Tell us how your software gets to production
Describe roughly how many repositories and pipelines you run, where they deploy, how runners are hosted and what prompted the question. We will suggest a scope from there.
To talk it through first, call +91 86868 92922 or email contact@berry9.com.
11 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
What are DevSecOps services?
They help a software team build security into the way code is written, built and released. In practice that means placing automated checks at the right points of the delivery pipeline, and reviewing the pipeline itself for weaknesses an attacker could use, such as exposed secrets, broad permissions or releases that nobody can verify. See the section on What DevSecOps services cover, and who needs them above.
What is a CI/CD pipeline security review?
It is an assessment of the system that builds and deploys your software, made from an attacker's point of view. The reviewer looks at who can change pipeline definitions, how secrets are stored and exposed, what build runners can reach, whether outputs are signed and checked, and how branch protection and deployment credentials are set up, then reports ranked findings with fixes. See the section on CI/CD pipeline security review from an attacker's view above.
What does shift-left security mean?
It means moving each security activity to the earliest phase of development where it can work: requirements and threat modeling during design, secure coding and automated checks while code is written and built, and testing before release. Problems found early are cheaper to fix, but shifting left adds to later testing rather than replacing it. See the section on Shift-left security across a secure SDLC above.
How much do DevSecOps services cost in India?
At BERRY9, a DevSecOps pipeline review starts from INR 27,000 + 18% GST; the final price is set in a written proposal after scoping. The main factors are how many pipelines and repositories are in scope, how many environments they deploy to, how build runners are hosted and whether templates and container images are reviewed too. See the section on What DevSecOps services cost above.
Does DevSecOps replace penetration testing?
No. Automated pipeline checks are good at catching known patterns on every change, but they cannot judge business logic, authorization rules or how small weaknesses combine. A penetration test of the running application, or a manual code review, finds those. Most teams that release often use pipeline checks continuously and a deeper test before significant releases. See the section on DevSecOps alongside code review, cloud, API and web testing above.
Which security checks should we add to our pipeline first?
Most teams start with the checks that are cheap to run and rarely wrong: scanning for secrets committed by mistake, and flagging third-party packages with published vulnerabilities. Checks on infrastructure templates and container images usually come next. Each new check should report without blocking at first, so the team can tune it before it stops a build. See the section on Where security checks sit in a CI/CD pipeline above.
What is container and infrastructure-as-code security review?
It checks the templates that create your cloud resources and the images your containers are built from, before they are deployed. Typical problems are storage open to the public, network rules wider than needed, permissions broader than the job requires, outdated base images and containers that run with administrator rights. See the section on Where security checks sit in a CI/CD pipeline above.
What access is needed for a pipeline security review?
Mostly read access: the repositories and pipeline definitions in scope, a view of pipeline settings, secret storage and runner configuration, and time with an engineer who knows the setup. The reviewer does not need the values of any secret to show that one is exposed. Any job that has to run is agreed in advance and runs where your team decides. See the section on What you receive, and what we need from you above.
How is secure SDLC consulting different from DevSecOps?
Secure SDLC work looks at the whole development life cycle, from security requirements and threat modeling to release approvals and incident lessons. DevSecOps is the part of that life cycle that lives in automation: the checks and controls inside the pipeline, and the security of the pipeline itself. A review of one often turns up gaps in the other. See the section on Shift-left security across a secure SDLC above.
Which pipelines and repositories should be reviewed first?
Start with the pipeline that builds and deploys the product your customers use, and the repositories that feed it, because a weakness there reaches production. Shared build templates, runners and the places secrets are kept are worth including early, since one fix there covers many projects. Work starts with a scoping conversation about your repositories, pipelines and environments, followed by a written proposal. See the section on What you receive, and what we need from you above.