carverauto/serviceradar

Fork 0

chore: missing file from last pr #3013

Merged

mfreeman451 merged 1 commit from refs/pull/3013/head into staging

2026-03-04 05:55:48 +00:00

mfreeman451 commented

2026-03-04 05:55:28 +00:00

(Migrated from github.com)

Owner

Imported from GitHub pull request.

Original GitHub pull request: #2990
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/2990
Original created: 2026-03-04T05:55:28Z
Original updated: 2026-03-04T05:58:02Z
Original head: carverauto/serviceradar:update/missing-file
Original base: staging
Original merged: 2026-03-04T05:55:48Z by @mfreeman451

IMPORTANT: Please sign the Developer Certificate of Origin

Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include
a DCO sign-off statement indicating the DCO acceptance in one commit message. Here
is an example DCO Signed-off-by line in a commit message:

Signed-off-by: J. Doe <j.doe@domain.com>

Describe your changes

Issue ticket number and link

Code checklist before requesting a review

I have signed the DCO?
The build completes without errors?
All tests are passing when running make test?

Imported from GitHub pull request. Original GitHub pull request: #2990 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/pull/2990 Original created: 2026-03-04T05:55:28Z Original updated: 2026-03-04T05:58:02Z Original head: carverauto/serviceradar:update/missing-file Original base: staging Original merged: 2026-03-04T05:55:48Z by @mfreeman451 --- ## IMPORTANT: Please sign the Developer Certificate of Origin Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include a [DCO sign-off statement]( https://developercertificate.org/) indicating the DCO acceptance in one commit message. Here is an example DCO Signed-off-by line in a commit message: ``` Signed-off-by: J. Doe <j.doe@domain.com> ``` ## Describe your changes ## Issue ticket number and link ## Code checklist before requesting a review - [ ] I have signed the DCO? - [ ] The build completes without errors? - [ ] All tests are passing when running make test?

qodo-code-review[bot] commented

2026-03-04 05:55:39 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR comment.

Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2990#issuecomment-3995486681
Original created: 2026-03-04T05:55:39Z

Review Summary by Qodo

Refactor TrivyReports processor with helper functions and severity mapping

✨ Enhancement

Walkthroughs

Description

• Add severity level mapping for atom-based severity classification
• Refactor context building with new helper functions for cleaner code
• Replace conditional chains with first_present/1 utility function
• Simplify event ID resolution logic and rename is_pod?/1 to pod?/1
• Extract severity normalization into separate helper functions

Diagram

flowchart LR
  A["Severity Mapping"] -->|atom-based| B["normalize_severity_level"]
  C["Context Building"] -->|first_present| D["Helper Functions"]
  E["Pod Detection"] -->|renamed| F["pod?"]
  G["Event ID Logic"] -->|simplified| H["if/else"]
  B --> I["Cleaner Code"]
  D --> I
  F --> I
  H --> I

File Changes

1. elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex ✨ Enhancement +79/-53

Refactor with severity mapping and extraction helpers

• Added @severity_level_map for mapping severity strings to atom values
• Introduced first_present/1 helper to replace chained || operators
• Refactored build_context/1 to use new helper functions for pod name, namespace, and UID
 inference
• Renamed is_pod?/1 to pod?/1 for consistency
• Simplified resolve_event_id/1 from cond to if/else structure
• Extracted severity normalization logic into normalize_severity_key/1 and updated
 normalize_severity_level/1
• Added infer_pod_name/3, pod_namespace_for/2, and pod_uid_for/2 helper functions

elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex

Imported GitHub PR comment. Original author: @qodo-code-review[bot] Original URL: https://github.com/carverauto/serviceradar/pull/2990#issuecomment-3995486681 Original created: 2026-03-04T05:55:39Z --- <h3>Review Summary by Qodo</h3> Refactor TrivyReports processor with helper functions and severity mapping <code>✨ Enhancement</code> <img src="https://www.qodo.ai/wp-content/uploads/2025/11/light-grey-line.svg" height="10%" alt="Grey Divider"> <h3>Walkthroughs</h3> <details open> <summary>Description</summary> <pre> • Add severity level mapping for atom-based severity classification • Refactor context building with new helper functions for cleaner code • Replace conditional chains with first_present/1 utility function • Simplify event ID resolution logic and rename is_pod?/1 to pod?/1 • Extract severity normalization into separate helper functions </pre> </details> <details> <summary>Diagram</summary> > ```mermaid flowchart LR A["Severity Mapping"] -->|atom-based| B["normalize_severity_level"] C["Context Building"] -->|first_present| D["Helper Functions"] E["Pod Detection"] -->|renamed| F["pod?"] G["Event ID Logic"] -->|simplified| H["if/else"] B --> I["Cleaner Code"] D --> I F --> I H --> I ``` </details> <img src="https://www.qodo.ai/wp-content/uploads/2025/11/light-grey-line.svg" height="10%" alt="Grey Divider"> <h3>File Changes</h3> <details> <summary>1. elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex <code>✨ Enhancement</code> <code> +79/-53 </code> </summary> >Refactor with severity mapping and extraction helpers ><pre> >• Added @severity_level_map for mapping severity strings to atom values >• Introduced first_present/1 helper to replace chained || operators >• Refactored build_context/1 to use new helper functions for pod name, namespace, and UID > inference >• Renamed is_pod?/1 to pod?/1 for consistency >• Simplified resolve_event_id/1 from cond to if/else structure >• Extracted severity normalization logic into normalize_severity_key/1 and updated > normalize_severity_level/1 >• Added infer_pod_name/3, pod_namespace_for/2, and pod_uid_for/2 helper functions ></pre> > ><a href='https://github.com/carverauto/serviceradar/pull/2990/files#diff-297fcb941eba6c81c53847017957a41b7b9b7c9bd3109cff80589cdf0a7a3d53'> elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex </a> <hr/> </details> <img src="https://www.qodo.ai/wp-content/uploads/2025/11/light-grey-line.svg" height="10%" alt="Grey Divider"> <a href="https://www.qodo.ai"><img src="https://www.qodo.ai/wp-content/uploads/2025/03/qodo-logo.svg" width="80" alt="Qodo Logo"></a>

qodo-code-review[bot] commented

2026-03-04 05:55:41 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR comment.

Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/2990#issuecomment-3995486738
Original created: 2026-03-04T05:55:41Z

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Duplicate severity mappings 🐞 Bug ✓ Correctness

Description

The PR introduces a second Trivy severity mapping (@severity_level_map) alongside the existing
@finding_severity_map. Because these two maps represent the same domain and are used in different
computation paths (counts vs numeric severity IDs), any future drift will produce inconsistent
severity counts/promotions/alerting behavior.

Code

elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[R53-61]

+  @severity_level_map %{
+    "critical" => :critical,
+    "high" => :high,
+    "medium" => :medium,
+    "low" => :low,
+    "none" => :informational,
+    "info" => :informational,
+    "informational" => :informational
+  }

Evidence
Two separate maps now encode the same Trivy severity keyspace. One drives numeric severity IDs
(finding_severity_id/1), while the other drives per-level counting (normalize_severity_level/1
-> increment_count/2). If a key is added/changed in one map and not the other, severity_id and
counts can disagree, which can impact promotion/alerting decisions derived from counts.
elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[43-61]
elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[974-979]
elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[1156-1161]
elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[807-823]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The module now contains two separate mappings for the same Trivy severity strings: one mapping to numeric severity IDs and another mapping to atom severity levels used as count keys. This duplication is error-prone: if a future change updates one mapping but not the other, severity counts and derived severity IDs can become inconsistent, impacting promotion/alerting decisions.

## Issue Context
- `finding_severity_id/1` uses `@finding_severity_map` (string -&gt; integer).
- `normalize_severity_level/1` uses `@severity_level_map` (string -&gt; atom) which is used to increment `empty_counts/0`.

## Fix Focus Areas
- elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[43-61]
- elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[974-979]
- elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[1156-1164]

## Suggested approach
- Define a single canonical list/structure like:
 - `@trivy_severities [{&quot;critical&quot;, :critical, 5}, ...]`
- Derive:
 - `@finding_severity_map` from that structure (string -&gt; int)
 - `@severity_level_map` from that structure (string -&gt; atom)
- Alternatively, remove one map and implement a single normalization function that returns a struct/tuple `{level_atom, severity_id}` or returns level_atom and separately translates to ID via `OCSF` constants.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

ⓘ The new review experience is currently in Beta. Learn more

Imported GitHub PR comment. Original author: @qodo-code-review[bot] Original URL: https://github.com/carverauto/serviceradar/pull/2990#issuecomment-3995486738 Original created: 2026-03-04T05:55:41Z --- <h3>Code Review by Qodo</h3> <code>🐞 Bugs (1)</code> <code>📘 Rule violations (0)</code> <code>📎 Requirement gaps (0)</code> <img src="https://www.qodo.ai/wp-content/uploads/2025/11/light-grey-line.svg" height="10%" alt="Grey Divider"> <img src="https://www.qodo.ai/wp-content/uploads/2026/01/review-recommended.png" height="20" alt="Remediation recommended"> <details> <summary> 1. Duplicate severity mappings <code>🐞 Bug</code> <code>✓ Correctness</code></summary> > <details open> ><summary>Description</summary> > > ><pre> >The PR introduces a second Trivy severity mapping (@severity_level_map) alongside the existing >@finding_severity_map. Because these two maps represent the same domain and are used in different >computation paths (counts vs numeric severity IDs), any future drift will produce inconsistent >severity counts/promotions/alerting behavior. ></pre> ></details> > <details open> ><summary>Code</summary> > > ><code>[elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[R53-61]](https://github.com/carverauto/serviceradar/pull/2990/files#diff-297fcb941eba6c81c53847017957a41b7b9b7c9bd3109cff80589cdf0a7a3d53R53-R61)</code> > >```diff >+ @severity_level_map %{ >+ "critical" => :critical, >+ "high" => :high, >+ "medium" => :medium, >+ "low" => :low, >+ "none" => :informational, >+ "info" => :informational, >+ "informational" => :informational >+ } >``` ></details> > <details > ><summary>Evidence</summary> > > ><pre> >Two separate maps now encode the same Trivy severity keyspace. One drives numeric severity IDs >(finding_severity_id/1), while the other drives per-level counting (normalize_severity_level/1 >-> increment_count/2). If a key is added/changed in one map and not the other, severity_id and >counts can disagree, which can impact promotion/alerting decisions derived from counts. ></pre> > > <code>[elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[43-61]](https://github.com/carverauto/serviceradar/blob/a2b500b0f85e8b3fc1aea900d6c6e5a9610665b5/elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex/#L43-L61)</code> > <code>[elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[974-979]](https://github.com/carverauto/serviceradar/blob/a2b500b0f85e8b3fc1aea900d6c6e5a9610665b5/elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex/#L974-L979)</code> > <code>[elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[1156-1161]](https://github.com/carverauto/serviceradar/blob/a2b500b0f85e8b3fc1aea900d6c6e5a9610665b5/elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex/#L1156-L1161)</code> > <code>[elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[807-823]](https://github.com/carverauto/serviceradar/blob/a2b500b0f85e8b3fc1aea900d6c6e5a9610665b5/elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex/#L807-L823)</code> ></details> > <details> ><summary>Agent prompt</summary> > > >``` >The issue below was found during a code review. Follow the provided context and guidance below and implement a solution > >## Issue description >The module now contains two separate mappings for the same Trivy severity strings: one mapping to numeric severity IDs and another mapping to atom severity levels used as count keys. This duplication is error-prone: if a future change updates one mapping but not the other, severity counts and derived severity IDs can become inconsistent, impacting promotion/alerting decisions. > >## Issue Context >- `finding_severity_id/1` uses `@finding_severity_map` (string -> integer). >- `normalize_severity_level/1` uses `@severity_level_map` (string -> atom) which is used to increment `empty_counts/0`. > >## Fix Focus Areas >- elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[43-61] >- elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[974-979] >- elixir/serviceradar_core/lib/serviceradar/event_writer/processors/trivy_reports.ex[1156-1164] > >## Suggested approach >- Define a single canonical list/structure like: > - `@trivy_severities [{"critical", :critical, 5}, ...]` >- Derive: > - `@finding_severity_map` from that structure (string -> int) > - `@severity_level_map` from that structure (string -> atom) >- Alternatively, remove one map and implement a single normalization function that returns a struct/tuple `{level_atom, severity_id}` or returns level_atom and separately translates to ID via `OCSF` constants. >``` > <code>ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools</code> ></details> <hr/> </details> <img src="https://www.qodo.ai/wp-content/uploads/2025/11/light-grey-line.svg" height="10%" alt="Grey Divider"> <pre>ⓘ The new review experience is currently in Beta. <a href="https://docs.qodo.ai/qodo-documentation/code-review">Learn more</a></pre> <img src="https://www.qodo.ai/wp-content/uploads/2025/11/light-grey-line.svg" height="10%" alt="Grey Divider">  <a href="https://www.qodo.ai"><img src="https://www.qodo.ai/wp-content/uploads/2025/03/qodo-logo.svg" width="80" alt="Qodo Logo"></a>