-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathsonar-project.properties
More file actions
123 lines (113 loc) · 8.14 KB
/
Copy pathsonar-project.properties
File metadata and controls
123 lines (113 loc) · 8.14 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
sonar.organization=getvictor
sonar.projectKey=getvictor_fleet-edr
sonar.projectName=fleet-edr
sonar.sources=.
sonar.tests=.
sonar.test.inclusions=**/*_test.go,**/*.test.ts,**/*.test.tsx,**/*Tests.swift
sonar.exclusions=**/vendor/**,**/node_modules/**,**/dist/**,ui/coverage/**,server/ui/dist/**,tmp/**,ai/**,extension/edr/build/**,extension/edr/tmp/**,extension/edr/**/DerivedData/**,extension/edr/**/*.xcodeproj/**,**/*.min.js,**/*.min.css
sonar.sourceEncoding=UTF-8
# Coverage uploads. Go reports flow through the native `go test -coverprofile`
# format that SonarCloud's Go analyser reads directly; UI reports are standard
# LCOV emitted by vitest's v8 provider. The test workflow splits Go tests
# into agent + server jobs (different runners, different MySQL needs) so
# each emits its own profile; Sonar merges overlapping coverage per file.
# Coverage report paths. The first two are Go profiles emitted by the
# per-language `go test -coverprofile=...` runs in CI's test.yml.
# coverage-server-e2e.out is a third Go profile produced by the
# Playwright E2E job: `go build -cover` instruments the server binary,
# Playwright drives the dev server end-to-end, and on shutdown the
# `go tool covdata textfmt` step merges the per-package profiles into
# a single textfmt file Sonar reads alongside the unit-test ones.
# Sonar's reader takes the UNION across all paths, so a line touched
# by either a unit test or an E2E run shows as covered.
sonar.go.coverage.reportPaths=coverage-agent.out,coverage-server.out,coverage-server-e2e.out
# UI LCOV report paths. lcov.info comes from vitest's v8 provider
# (tests under ui/src/**/*.test.{ts,tsx}). lcov-e2e.info is the
# Playwright-captured V8 coverage of the running React bundle,
# converted to LCOV via monocart-coverage-reports (which walks the
# embedded Vite source maps so the paths point at ui/src/** rather
# than the minified dist assets). Either source covering a line is
# sufficient for Sonar.
sonar.javascript.lcov.reportPaths=ui/coverage/lcov.info,test/e2e/coverage/lcov-e2e.info
# Exclude from coverage the files that are intentionally not tested OR
# whose coverage isn't reported by any tooling we have wired up. Keeping
# these in scope would artificially drag the "Coverage on New Code"
# gate down any time one of them gets edited, even though zero of those
# edits are actually testable from where we sit today.
#
# - **/cmd/**/main.go one-time process wiring, naturally 0%.
# - server/detection/testharness/** exercised transitively by every rule
# test that imports it; itself untested.
# - schema/** JSON schema, no test surface.
# - extension/edr/** Swift agent code; we don't yet upload
# Swift coverage to Sonar, so every Swift
# file would be 0% by default.
# - agent/receiver/** CGo bridge; needs a running ESF + NE
# link, no unit-testable surface.
# - server/bootstrap/** process-init wiring, called once.
# - server/httpserver/** net/http server lifecycle wiring.
# - test/** load-test harness, not production code.
# - tools/** Build-time CLIs (tools/gen-rule-docs
# generates docs/detection-rules.md).
# Tested at the package level, but the
# project's coverage profiles upload only
# ./agent/... and ./server/... so the
# generator's lines never reach Sonar
# even though they ARE exercised.
# - ui/src/** REMOVED. The Playwright E2E run captures
# V8 coverage of the running React bundle
# and emits an LCOV via monocart-coverage-
# reports (sourcemap-remapped back to
# ui/src). Sonar reads it as a second
# sonar.javascript.lcov.reportPaths entry.
# - ui/vite.config.ts Build-tool config (analogous to
# **/cmd/**/main.go on the Go side):
# one-time wiring that runs at `vite
# build` time, not under any test
# runner. No test reaches it, so it
# always drags the new-code coverage
# gate to 0% when edited.
# **/*_windows.go and **/*_other.go are platform-variant files (ADR-0018): the Windows variants and the non-primary-platform stubs
# never execute on the macOS + Linux coverage runners, so they cannot be covered until a Windows CI runner lands. Their correctness is
# gated by the cross-compile + vet invariant (task build:agent:windows), the same way agent/receiver/** (the non-darwin stub) is handled.
sonar.coverage.exclusions=**/cmd/**/main.go,**/cmd/**/sensors*.go,server/detection/testharness/**,schema/**,extension/edr/**,agent/receiver/**,server/bootstrap/**,server/httpserver/**,test/**,tools/**,ui/vite.config.ts,ui/src/test/**,**/*_windows.go,**/*_other.go
# Per-rule suppressions. Sonar's secrets analyser (secrets:S8215) flags the
# bcrypt password hashes in config/dex/dev-config.yaml + config/dex/demo-config.yaml
# as BLOCKER vulnerabilities. Those hashes are intentional dev-fixtures: dev-config.yaml
# pins the four pre-provisioned dex users for `task qa:up` + the Playwright OIDC tests
# (plaintext qa-password-123), and
# demo-config.yaml pins the single SSO user for the Mac-free docker demo
# (docker-compose.demo.yml; plaintext "demo", documented in the README + the file
# header). Each file's header comment plus its path under config/dex/ make the dev-only
# intent obvious; the rule still fires because Sonar can't distinguish dev fixtures from
# production secrets. Suppressing the rule for these exact files keeps the gate honest for
# prod-bound credentials anywhere else in the tree.
sonar.issue.ignore.multicriteria=dexDevHashes,dexDemoHashes,migrationDdlLiterals
sonar.issue.ignore.multicriteria.dexDevHashes.ruleKey=secrets:S8215
sonar.issue.ignore.multicriteria.dexDevHashes.resourceKey=config/dex/dev-config.yaml
sonar.issue.ignore.multicriteria.dexDemoHashes.ruleKey=secrets:S8215
sonar.issue.ignore.multicriteria.dexDemoHashes.resourceKey=config/dex/demo-config.yaml
# goose migration files are MySQL DDL, but Sonar analyses them with its PL/SQL
# analyser, which fires plsql:S1192 ("define a constant instead of duplicating
# this literal") on repeated column DEFAULT / ENUM values like 'system' and
# 'NONE'. DDL has no construct to hoist a default into a constant, and the
# baselines are the pre-goose schema frozen verbatim (byte-identical invariant,
# ADR-0009), so the literals cannot change anyway. Suppress S1192 for migration
# SQL only; genuine SQL issues on these files still surface under other rules.
sonar.issue.ignore.multicriteria.migrationDdlLiterals.ruleKey=plsql:S1192
sonar.issue.ignore.multicriteria.migrationDdlLiterals.resourceKey=**/migrations/*.sql
# Exclude static catalog / lookup tables from copy-paste duplication detection.
# Files where every entry repeats the same property names (id/name/tactic per
# row, etc.) are 60-90% "duplicated" by Sonar's CPD heuristic, but it's not
# real code duplication - it's data shape. The new-code duplication gate
# (3% threshold) goes ERROR on a single such file. Add specific paths here
# rather than a broad glob so genuinely repetitive code doesn't sneak past.
#
# - ui/src/components/attack-techniques.ts MITRE ATT&CK technique catalog
# (id/name/tactic per technique).
sonar.cpd.exclusions=ui/src/components/attack-techniques.ts
# Skip C/C++/Objective-C analysis (requires a compilation database we don't generate).
# The only C in the repo is small CGo bridge files in agent/.
sonar.c.file.suffixes=-
sonar.cpp.file.suffixes=-
sonar.objc.file.suffixes=-