Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(metrics): audited/unaudited by policy violation state #3615

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

setchy
Copy link
Contributor

@setchy setchy commented Apr 13, 2024

Description

Add support for audited/unaudited policy violation metrics by state (fail, warn, info)

Addressed Issue

Closes #3612

Additional Details

Checklist

  • I have read and understand the contributing guidelines
  • This PR fixes a defect, and I have provided tests to verify that the fix is effective
  • This PR implements an enhancement, and I have provided tests to verify that it works as intended
  • This PR introduces changes to the database model, and I have added corresponding update logic
  • This PR introduces new or alters existing behavior, and I have updated the documentation accordingly

@setchy setchy force-pushed the feature/violation-state-audit-unaudit branch from 72757a0 to 2eb8b7e Compare April 13, 2024 09:12
@setchy setchy marked this pull request as draft April 13, 2024 09:51
Copy link

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation Diff coverage
+0.54% (target: -1.00%) 98.90% (target: 70.00%)
Coverage variation details
Coverable lines Covered lines Coverage
Common ancestor commit (c15560b) 21606 16001 74.06%
Head commit (145056a) 21868 (+262) 16313 (+312) 74.60% (+0.54%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details
Coverable lines Covered lines Diff coverage
Pull request (#3615) 182 180 98.90%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

You may notice some variations in coverage metrics with the latest Coverage engine update. For more details, visit the documentation

@setchy
Copy link
Contributor Author

setchy commented May 9, 2024

@nscuro - would love to target 4.12.x milestone for this

@nscuro nscuro added this to the 4.12 milestone May 9, 2024
@nscuro nscuro added the enhancement New feature or request label May 9, 2024
@setchy
Copy link
Contributor Author

setchy commented Jun 26, 2024

@nscuro - any feedback you or the team have re: this enhancement?

@nscuro nscuro self-assigned this Jun 26, 2024
@nscuro
Copy link
Member

nscuro commented Jun 26, 2024

@setchy I'll have a look and provide feedback by EOW.

Copy link
Member

@nscuro nscuro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good enhancement overall, just needs some clarification so we can avoid breaking changes.

Comment on lines 111 to +113
@Persistent
@Column(name = "POLICYVIOLATIONS_WARN", allowsNull = "true") // New column, must allow nulls on existing data bases)
@Column(name = "POLICYVIOLATIONS_FAIL_TOTAL", allowsNull = "true") // New column, must allow nulls on existing databases)
private Integer policyViolationsFailTotal;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a breaking change in both the database schema (or rather the data is holds), as well as the REST API. I know it's not pretty, but we should keep using the policyViolationsFail field and column.

We can add a new policyViolationsFailTotal getter that just returns policyViolationsFail - that would make the new field available via REST API without breaking semantics of the old field, and it would not require a migration of existing data.

Alternatively, we need to migrate all data from POLICYVIOLATIONS_FAIL to POLICYVIOLATIONS_FAIL_TOTAL, drop the POLICYVIOLATIONS_FAIL column, and must ensure that policyViolationsFail and policyViolationsFailTotal return the same value in the REST API.

if (counters.policyViolationsSecurityTotal > 0) {
counters.policyViolationsSecurityAudited = toIntExact(getTotalAuditedPolicyViolations(pm, component, PolicyViolation.Type.SECURITY));
counters.policyViolationsSecurityUnaudited = counters.policyViolationsSecurityTotal - counters.policyViolationsSecurityAudited;
if (BooleanUtils.isTrue(violation.suppressed)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should check for BooleanUtils.isFalse(violation.suppressed) instead. Suppressed findings and violations are counted separately and are not included in *Audited metrics.

@nscuro nscuro modified the milestones: 4.12, 4.13 Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enhance metrics to include audited/unaudited violations by classification
2 participants