GitHub Advanced Security and DevSecOps Implementation

Enablement and configuration of GitHub Secret Protection and GitHub Code Security across up to 25 repositories in up to two organizations, on GitHub or on Azure DevOps: push protection and full-history secret scanning with validity checks and custom patterns, CodeQL code scanning, dependency scanning or dependency review on pull requests, merge gates at severity thresholds your team agrees, guided triage of the existing alert backlog, an optional Defender for Cloud DevOps security connector, a written DevSecOps playbook and a live enablement session. Fixed price $3,950, about 2 weeks.

No. Since 2025 the suite is sold as two standalone products rather than one Enterprise-only bundle: GitHub Secret Protection and GitHub Code Security. You need to be on a GitHub Team or Enterprise plan to purchase them — the Free plan cannot — and they are billed per active committer per month, with list prices at the time of writing of $19 for Secret Protection and $30 for Code Security. Public repositories on github.com get secret scanning, push protection and code scanning free of charge; the products are what bring those features to your private repositories.

Two separate things. Our fee is $3,950, fixed, quoted in writing before we start, payable after you approve delivery. GitHub's or Microsoft's per-active-committer charges are yours and continue every month after we leave. That is precisely why the first milestone produces a committer estimate and a monthly figure before billing is switched on — a 20-developer team enabling both products is a materially different monthly number from the same team enabling Secret Protection alone, and you should see it before you commit, not after.

A committer is active if a commit of theirs was pushed to a repository with the product enabled in the last 90 days, regardless of when it was written. Each active committer consumes one licence per product, deduplicated across repositories and organizations within the same enterprise or the same linked Azure subscription — so GitHub App bots are ignored on GitHub, and the same developer working in ten repositories still costs one licence. You control the bill mainly by choosing which repositories are enabled and which products they need, not by moving people around; we show you the estimate for each option at kickoff.

Both, and the engagement covers one of them at the fixed price. On Azure DevOps the same two products ship as GitHub Secret Protection for Azure DevOps and GitHub Code Security for Azure DevOps, enabled from organization, project or repository settings and billed to the Azure subscription linked to your organization. Two constraints matter: they run on Azure DevOps Services only — not Azure DevOps Server — and only on Git repositories, so TFVC repositories cannot be scanned.

Only where you decide it should. Merge gates are configured to a threshold your engineering lead agrees, and we normally start with new critical and high findings only, so an existing backlog does not halt delivery on day one. On Azure DevOps that is the AdvancedSecurity/NewHighAndCritical status check as a branch policy, moving to AllHighAndCritical once the backlog is cleared; on GitHub it is the equivalent required checks on protected branches. Tightening the threshold later is a settings change your team can make alone — the playbook explains how.

That is the usual failure mode, and the sequencing exists to prevent it. Secret Protection goes on first, because a leaked credential that still works is the finding that actually matters, and validity checks let us rank alerts by whether the secret is live rather than by when it was committed. Code Security follows, and its backlog is triaged down to the agreed severity threshold with your developers in the room. Everything below the threshold is handed over as a ranked list rather than pretended away.

No — and any provider who promises to inside a two-week fixed price is promising something else. We triage with your developers, rank findings, dismiss false positives with written reasons, and produce a rotation runbook for leaked credentials. Changing application code and rotating secrets in the systems that issued them stays with your team, or becomes a separately quoted engagement. If you want the ongoing work covered, Managed Vulnerability Remediation is the retainer for it.

It implements and evidences the control those frameworks and questionnaires ask about — secret scanning, dependency and code scanning, and enforced review before merge — and the security overview plus the evidence export give you something concrete to show. No implementation can promise an audit outcome, because auditors assess your whole programme rather than one tool. If the audit itself is the goal, the SOC 1, SOC 2, ISAE 3402 and ISO 27001 pre-audit readiness assessments are the right starting point, and Cyber Insurance Readiness Assessment covers the insurer's version of the same questions.

On GitHub, the dependency graph and Dependabot alerts are available on every plan, including without these products — what Code Security adds is dependency review in pull requests, custom auto-triage rules for managing alerts at scale, and security overview. We configure all of it, including the alert routing and rules that make the volume survivable. On Azure DevOps there is no Dependabot: dependency scanning is a pipeline-based capability of Code Security, enabled either through the default setup for your default branch and pull-request builds or by adding the scanning task to the pipelines you want covered.

It reads a CodeQL code-scanning alert and proposes a targeted code change for a developer to review and merge — it suggests, it does not remediate on its own. On GitHub it is included with Code Security and we configure it. On Azure DevOps it is in limited public preview and Microsoft is not currently accepting additional preview users, so this service does not promise it there; if your organization already has preview access we enable it, and it applies only to CodeQL alerts, never to secret or dependency findings.

Not for the scanning itself — this service works without it. The optional DevOps security connector is useful when your security team already lives in Defender for Cloud and wants repository and pipeline posture next to the rest of the cloud estate. Connecting the organization, inventory and DevOps posture recommendations are available at the free foundational tier; attack path analysis, cloud security explorer and pull-request annotations for infrastructure-as-code findings require the paid Defender CSPM plan. DevOps security also runs in the Azure commercial cloud in selected regions only, and its GitHub support is for GitHub Enterprise Cloud — so a Team-plan organization gets the scanning products but not the connector. If posture management across your cloud is the wider goal, that is Microsoft Defender for Cloud — Cloud Security Posture Management.

About 2 weeks. We need owner or Project Collection Administrator access, plan eligibility confirmed, written approval to begin per-committer billing once you have seen the estimate, an engineering lead to sign off severity thresholds, and developers available for the triage and enablement sessions. The usual sources of delay are billing approval and developer availability for triage, both of which extend the calendar rather than the fixed price.

Your team owns it, which is the point of the playbook: named triage owners, severity response times, a documented bypass and exception process, the secret rotation runbook, and the evidence export you will need the next time a customer sends a questionnaire. Adding repositories or a second organization later is a small quoted add-on rather than a repeat of this engagement. If you would rather not own the ongoing triage, continuous monitoring, out-of-hours coverage and escalation to Microsoft under our Premier Support agreement are available as optional extra-cost add-ons.