Datadog Code Coverage
You set up datadog code coverage by sending test reports from your build runner. The runner collects line data during tests and uploads the results to your account. Teams often add shared API keys to build jobs to make this work fast. Broad permissions on those keys create big security risks across all your test systems. How datadog code coverage works in build pipelines A test tool runs your unit tests and tracks which code lines execute. The tool writes a report file at the end of the test
Infrastructure as Code Security Scanning + Datadog Security Monitoring: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up datadog code coverage by sending test reports from your build runner. The runner collects line data during tests and uploads the results to your account. Teams often add shared API keys to build jobs to make this work fast. Broad permissions on those keys create big security risks across all your test systems.
How datadog code coverage works in build pipelines
A test tool runs your unit tests and tracks which code lines execute. The tool writes a report file at the end of the test run. Next, a reporter step in your pipeline reads that file from the runner disk. It attaches git metadata like the branch name and commit hash to the payload. Then it sends the report over the network to the vendor intake server. The platform links those line metrics to your pull requests and test histories.
Teams use this flow to spot untested code before merging a new change. Developers can see if a pull request drops the total coverage number. They can also track which specific files lack good test coverage over time. This setup relies on valid keys stored inside the build job settings. Every build runner needs permission to send data to the remote intake endpoint. Without strict scoping, those keys might grant more power than a simple upload needs.
What native reporting solves and what gaps remain
Native coverage tracking helps engineering teams keep code quality high across many repos. It gives clear feedback on every commit and stops bad merges early. Managers get a central view of test health without reading raw build logs. Yet this setup only handles metric collection and dashboard display for your team.
The native workflow does not solve how runners handle secrets and database sessions. Integration tests often need real database queries or internal service calls to check logic. Teams end up placing static database passwords right next to their reporting keys. A build setting decides who logs in, not what individual statements do in flight. If a test runner gets compromised, attackers can grab those stored database credentials. They can run broad queries that expose sensitive data like emails or card numbers. You need a way to control runtime queries and mask sensitive fields in results.
Infrastructure as Code Security Scanning + Datadog Security Monitoring: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing test runners during coverage runs
Good test coverage often requires running integration suites against staging or test databases. Static credentials in build pipelines make it hard to track who ran which query. Shared test accounts hide which job or developer triggered a specific database command. Scoping down runner permissions reduces the blast radius of a leaked build secret.
Teams should separate metric upload keys from the credentials used for test data. Every database query during a test run should pass through strict runtime checks. Masking rules can rewrite emails, phone numbers, and national IDs in query results. This keeps real customer data out of test logs and coverage failure outputs. You also get a clear audit log of every command run during tests.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does datadog code coverage run tests by itself?
No, your own test tool runs the tests and generates the report file. The platform only ingests that file to display metrics and track trends.
Why do coverage runs create security risks in CI pipelines?
Integration tests often use static database keys stored in the pipeline settings. If those keys leak, attackers gain broad permissions to read your test databases.
How can teams protect sensitive data during integration tests?
Teams can apply runtime masking that rewrites emails and card numbers in query results. This stops sensitive values from leaking into build logs or test reports.