Skip to content

CHORE: add shift-left secret scanning to PR validation (test)#674

Draft
bewithgaurav wants to merge 6 commits into
mainfrom
bewithgaurav/test-secret-scan-shift-left
Draft

CHORE: add shift-left secret scanning to PR validation (test)#674
bewithgaurav wants to merge 6 commits into
mainfrom
bewithgaurav/test-secret-scan-shift-left

Conversation

@bewithgaurav

Copy link
Copy Markdown
Collaborator

Work Item / Issue Reference

ADO Work Item: Fixed AB#<WORK_ITEM_ID>


Summary

draft / test — do not merge. proving shift-left secret scanning on PR validation.

adds a SecretScan job to eng/pipelines/pr-validation-pipeline.yml that runs 1ESSecretScanning@1 (the SEC101 / SPMI engine, same family as the ADO push-protection SEC101/037 SqlLegacyCredentials signal) + PostAnalysis@2 to fail the build on any finding. goal: catch credential leaks at PR time, pre-merge, instead of surfacing later at the GitHub→ADO sync push-protection gate.

tests/_secretscan_probe.txt is a clearly-fake, non-live Azure-SQL-cred-shaped string planted only to verify detection end-to-end. expected result: the Secret Scan leg fails on this probe. once detection is confirmed, the probe file is removed and the scan should pass.

both the probe and the placement of the job are test scaffolding for evaluation.

adds a SecretScan job to the pr-validation pipeline that runs the 1ES Secret Scanning (SEC101/SPMI) engine on every PR, so credential leaks like SEC101/037 SqlLegacyCredentials are caught pre-merge instead of at the GitHub->ADO sync. includes a clearly-fake planted probe fixture to verify detection end-to-end; both the fixture and (pending decision) the job are test scaffolding.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions

github-actions Bot commented Jul 10, 2026

Copy link
Copy Markdown

📊 Code Coverage Report

🔥 Diff Coverage

100%


🎯 Overall Coverage

80%


📈 Total Lines Covered: 6743 out of 8343
📁 Project: mssql-python


Diff Coverage

Diff: main...HEAD, staged and unstaged changes

No lines with coverage information in this diff.


📋 Files Needing Attention

📉 Files with overall lowest coverage (click to expand)
mssql_python.pybind.logger_bridge.cpp: 59.2%
mssql_python.pybind.ddbc_bindings.h: 59.9%
mssql_python.pybind.logger_bridge.hpp: 70.8%
mssql_python.pybind.connection.connection.cpp: 76.2%
mssql_python.pybind.ddbc_bindings.cpp: 76.2%
mssql_python.__init__.py: 77.3%
mssql_python.row.py: 77.6%
mssql_python.ddbc_bindings.py: 79.6%
mssql_python.connection.py: 83.6%
mssql_python.logging.py: 85.5%

🔗 Quick Links

⚙️ Build Summary 📋 Coverage Details

View Azure DevOps Build

Browse Full Coverage Report

Copilot AI added 5 commits July 13, 2026 19:17
the previous PostAnalysis@2 step did not fail the build on 1ESSecretScanning findings (its break filter does not cover the secret scanner, and SPMI emits warnings not errors) - so the planted probe was detected but the run stayed green. replace it with a SARIF gate script that parses the SEC101 findings, ignores the sample-credential paths already excluded by .config/CredScanSuppressions.json (tests/benchmarks/eng/OneBranchPipelines), and fails the build on any remaining leak in shipping source. move the test probe to repo root so it is treated as a real (non-sample) leak.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
previous commit only captured the probe move; the pipeline edit (swap PostAnalysis@2 for the PowerShell gate) and the gate script itself were missed. add them so the SecretScan job actually references an existing script.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
the gate passed even though the scanner flagged the root probe: Get-ChildItem -Recurse skips the hidden .gdn results dir without -Force, so it matched an unrelated empty SARIF. target <BuildDir>/.gdn/.r directly with -Force (fallback to a forced recursive search) and add diagnostics on which SARIF files and how many SEC101 results are seen.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
the gate read the right SARIF but saw 0 SEC101: SPMI stores the rule id via ruleIndex into tool.driver.rules[], not always in result.ruleId. resolve the id from result.ruleId, result.rule.id, or the rules table, match SEC101 anywhere, and log each result's ids for diagnosis.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
detection proven (build failed on the root probe with SEC101/037 while ignoring the sample creds under tests/). remove the probe so the gate now passes on a clean tree, and drop the per-result debug line.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants