DevSecOps consulting services
Every CI/CD platform (the system that builds, tests and releases your code) documents a way to switch a security check off. We settle what blocks a release, what only warns, and who may bypass a check, with a record.
What we settle
Fast releases come from checks people trust: a check blocks only when it has earned it, and an urgent fix gets a recorded way through.
A check blocks only if it meets Google's published bar: easy to act on, never stopping correct code, old findings cleared first so no build breaks on untouched code. Otherwise it warns; Google counts a warning nobody acts on as an "effective false positive".
We list everyone who can get past each check, from branch protection, rulesets and skip settings.
Each exception carries a reason, a duration, a named approver and a periodic review, logged in your own tracking system.
The off switch is a feature
A team adds a static analysis job (SAST: a tool that reads source code for flaws), marks the check required and records the control as in place. Nobody writes down who may turn it off; whoever last edited the pipeline file and repository settings already decided.
So the choice is never gate or no gate, but a governed bypass or an undocumented one. CERT-In's Guidelines for Secure Application Design, Development, Implementation & Operations say it at section 6.3: "Implement and maintain secure build and deployment pipelines with robust enforcement of security checks."
The documented ways out
We look for each one at scoping.
| Switch | Effect on the gate | Where it is set |
|---|---|---|
GitLab allow_failure | The job shows "an orange warning (status_warning)", yet the pipeline passes. | .gitlab-ci.yml, per job. |
GitHub Actions continue-on-error | Turns a blocking job or step into an advisory one. | The workflow file, per job or per step. |
| A required check that reports skipped | A job whose if: condition evaluates false reports skipped, which satisfies the rule. | The job's conditions, not the branch protection. |
| GitHub branch protection defaults | Rules don't apply to repository admins or custom roles holding the bypass permission. | "Do not allow bypassing the above settings" covers them. |
| GitHub rulesets bypass list | Admins, owners, maintain or write roles, teams, GitHub Apps and Dependabot, each "Always allow" or "For pull requests only"; only the second still requires a pull request. | The ruleset's bypass list. |
| GitLab skip directives | [ci skip], [skip ci] or the ci.skip push option (which "does not skip merge request pipelines") runs no jobs; an empty pipeline shows Skipped. | The commit message or push, at a developer's keyboard. |
git commit --no-verify | "Bypass the pre-commit and commit-msg hooks." | Git itself. A server-side check is a separate control. |
GitLab's control over [skip ci] | "Pipeline execution policies and scan execution policies can restrict or disable the [skip ci] directive." | GitLab pipeline and scan execution policies. |
How we work
Your pipeline files, not a description, plus your branch protection or ruleset export.
Which required checks can report "skipped", every switch in front of a security check, and a count of findings per tool and repository, so you know beforehand how much work blocking would create. The count is your tools' output, not our risk rating.
If your exception rules don't exist yet, we write them before any check starts blocking.
Block or only warn, judged against Google's published bar, with the severity that blocks a release set in writing.
The gate register, the change specification, and a note linking each gate to the clause you cite, saying what it does and does not show an auditor.
Stage by stage
Each task comes from NIST SP 800-218, the Secure Software Development Framework (SSDF) Version 1.1, February 2022, which "does not prescribe how to implement each practice" and is not a checklist. CERT-In section 3.2 lists the SSDF among four secure development models.
OWASP's pre-commit chapter covers secrets management and linting; NIST PS.1.1 covers "source code, executable code, and configuration-as-code". OWASP's vulnerability scanning chapter covers SAST, DAST (testing the running application), interactive testing, software composition analysis, and infrastructure and container scanning. NIST PW.7.2 Example 6 asks your automated tools to find and fix unsafe practices continuously as code is checked in: your toolchain, not a service SecWiz runs.
PW.6.2 asks you to choose and approve compiler, interpreter and build tool settings, then use only those. Example 2 is a "clean build", with warnings treated as errors except named false positives; Example 3, "Perform all builds in a dedicated, highly controlled build environment"; Example 7, approved settings as configuration-as-code. CERT-In section 6.1 asks for security measures on Docker, Kubernetes and Jenkins, and no changes to audited code or configurations. CICD-SEC-4's Indirect Poisoned Pipeline Execution runs through Makefiles, build scripts, test files and linter configurations, so they are in scope.
PS.2.1 asks you to give software acquirers integrity verification information; PS.3.2, to keep provenance data for each release, for example in a software bill of materials (SBOM). SLSA v1.2, the current Approved specification, has a Build track (L0 to L3) and a Source track (L1 to L4). It does not show whether developers coded securely, and "provenance doesn't do anything unless somebody inspects it", so verification gets a named owner and a named behavior on failure. CICD-SEC-9 asks for third-party hashes and signatures to be checked before use.
CERT-In section 4.15 asks organizations to keep an SBOM and avoid vulnerable components. SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF), GV.SC.S5, requires an SBOM for new software procurements of core and critical activities, kept updated with every upgrade or change, and lists nine contents, among them transitive dependencies, component hashes and "Known unknown (where a SBOM does not include a full dependency graph)". If one cannot be obtained for a legacy or proprietary system, the Board, Partners or Proprietor must approve that "with proper limitation, rationale, and risk management approach". A default generator meets some items, not all.
PW.8.2 puts dynamic vulnerability testing, and tests for previously reported vulnerabilities, into the automated suite. PO.4 is "Define and Use Criteria for Software Security Checks"; PO.4.2 adds periodic review of automated decisions and records protected from alteration. PO.3.1 asks you to specify each toolchain's tools and how they connect; PO.3.3, to make tools produce evidence. If that specification doesn't exist yet, we write it. A draft SSDF Version 1.2 (17 December 2025) is not final.
Scope and limits
SecWiz applies nothing to your repositories or pipeline. Your engineers make every change.
SecWiz does not operate the gate or hold a triage queue for it. If you want it run day to day, this is the wrong purchase.
SecWiz is not CERT-In empanelled. Where a clause requires an empanelled auditor, our note says so, and your auditor decides.
A bounded engagement. Monitoring set-up (SOC readiness), incident response and ongoing managed security retainers are separate engagements.
Related: vulnerability triage for existing findings, secure code review, threat modeling, cloud security review, GRC and compliance for the audit side, fintech and banking, and all defensive security services.
FAQ
One decision per security check in your CI/CD pipeline: block or warn, who may bypass it, and what that bypass records, checkable against the OWASP DevSecOps Guideline and NIST SP 800-218. You get the exact settings and the reason for each; your engineers, not SecWiz, apply them.
No. SecWiz does not operate the gate or hold a triage queue for it; the scope names who does after handover. Monitoring set-up (SOC readiness), incident response and ongoing managed security retainers are separate engagements.
Not necessarily. GitHub states that "Required status checks must have a successful, skipped, or neutral status before collaborators can make changes to a protected branch." A job whose condition evaluates false reports skipped, so the pull request goes green with nothing having run.
On Tricorder, Google's analysis platform, a check needs less than 10% effective false positives to appear at code review. To break the build it must be actionable, "Produce no effective false positives (the analysis should never stop the build for correct code)", and flag only correctness issues, with existing instances cleaned up first. Otherwise it warns.
Only if it has no exception path. NIST PO.4.1 Example 5 asks you to record approvals, rejections and exception requests. SEBI's CSCRF (PR.IP.S3 guideline 3, for "All REs except small-size, self-certification REs") asks for justification, duration, a granting process, an approving authority and periodic review. CERT-In (section 4.7) asks for deviation conditions to be identified in advance. The urgent fix ships through that path, with a record.
No. SEBI's CSCRF (circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113, 20 August 2024), PR.IP.S15 guideline 1, requires DAST, SAST and a "Software bill of material (SBOM)" for critical-system software, for "All REs (Mandatory)". Guideline 5 requires compliance for in-house developed software to be submitted by a CERT-In empanelled IS auditing organization. SecWiz is not one, so your auditor decides.
On opposite sides of the production boundary. CERT-In's guidelines (section 4.8) put a static scan of source code before deployment to production, then a dynamic scan of the live application, so a DAST job with nothing deployed checks nothing. SEBI's CSCRF, PR.IP.S15 guideline 2, adds that "Application security testing shall also include API security and API discovery".
The pipeline files, not a description: every .gitlab-ci.yml, .github/workflows file or Jenkinsfile in scope, plus the templates, Makefiles, build scripts, test files and linter configurations they call. Then your ruleset or branch protection export with its bypass list, where builds run, whether fork pull requests reach secrets, and a baseline count of findings per tool.
Let's talk
Share your pipeline files and bypass list. We'll tell you which checks can block today, which can't yet, or that the exception path must come first. We reply within one working day.