coverity-scan

name	coverity-scan
description	Use this to run static analysis over components in the entservices repo and generate a master report. Use this when you are asked to run a Coverity Scan and produce the CSV report for the scanned components.

Coverity Scan Skill

To perform static analysis, consider the following instructions. As a static code analyzer for RDK repositories, your analysis should perform a static analysis of the repo's components and code files, similar to a Coverity Scan, and identify issues such as defects, security vulnerabilities, and maintainability concerns. You MUST follow the below workflow and formatting rules exactly.

PART 1 — Create / Reuse the Master Excel-Compatible Report (CSV)

• If the user had specified a branch, use it; if not, create a new branch from develop with this naming convention: copilot/coverity-analysis-{YYYY_MM_DD-HH.MM.SS}.

• All CSV and analysis work happens on this branch.

• The report MUST be a CSV.

• For the creation and modification of the CSV, write the CSV directly; do not use a program or Python script to create it.

• Do not use external tools.

  Report Name: {repoName}_workspace_static_analysis.csv Location: .github/agent_output/reports

CSV Columns (EXACT ORDER): Row ID Number,Component Name,File Path,Line Number,Source Code Snippet,Issue Type,Severity,Issue Description,Suggested Fix

Manual Verification (required): Before writing anything, inspect the .github folder of the specified branch's root to confirm whether {repoName}_workspace_static_analysis.csv already exists with these columns. Only create a new CSV if it is missing; otherwise reuse the existing file and append rows.

---

PART 2 — Proceed with Component-By-Component Static Analysis

For each component (i.e. each top-level folder or subsystem in the repo root), perform static analysis using the following steps. List the components as is; do not invent ad hoc component names from individual file paths.

Working directory for analysis: Entire entservices repo Components(Root Folders and Subsystems) to analyze now: Use existing tools to perform component discovery and enumerate every eligible top-level folder/subsystem exactly once.

2.1 — File Coverage Requirements (ZERO TOLERANCE)

For each component, analyze ALL of the following file types present in the component (must include all):

• .c
• .cpp
• .cc
• .h
• .hpp
• .inl

Including (must not skip):

• All subfolders
• Platform-specific variations
• Inline header implementations
• Internal helpers and utilities

Use read_file with endLine: 99999 (or equivalent) so every file is read completely. Zero tolerance for skipped or partially read files.

2.2 — Static Analysis Requirements (deep, manual)

For each file in each component, detect these issue types (at minimum):

• Memory leaks
• Use-after-free
• Null dereferences
• Buffer overflows / bounds violations
• Concurrency race conditions
• API misuse
• Incorrect error handling
• Resource leaks
• Undefined behavior
• Logic defects
• Security vulnerabilities
• Unbounded recursion
• Dead code
• Performance issues
• Incorrect lifetime handling
• Misleading constructs
• Coding guideline violations

2.3 — Reporting for Manual Issues (append to SAME CSV)

For EVERY issue found in each component, append ONE CSV row with:

• Component Name: the exact current top-level folder/subsystem name being analyzed
• Exact File Path (root-relative)
• Exact Line Number(s), using a single line number or an inclusive line range when one issue spans multiple contiguous lines
• Source Code Snippet (IMPORTANT: ensure double quotes are properly escaped)
• Issue Type: Category from detection criteria above
• Severity: Critical | High | Medium | Low
• Issue Description
• Suggested Fix If there is a component with no issues, add a row with "No issues found" in the Issue Description column and leave other fields blank except Component Name and File Path.

---

PART 3 — Perform a Check to Ensure all Component(s) Have Been Analyzed

Check the created CSV to confirm that every component in the repo has been analyzed and has either issues reported or explicitly marked as "No issues found". If any component is missing from the CSV, or if any component has no corresponding rows, return to PART 2 and analyze the missing component(s).

3.1 — CSV Validation:

• Verify CSV has all required columns
• Verify all standard issue rows have all 9 fields populated
• Verify every eligible top-level folder/subsystem has been analyzed and added to the CSV
• Exception: "No issues found" rows only require Component Name and File Path to be populated; all other fields may be left blank
• Count total issues in CSV

3.2 — Status Report:

• Report component names found and analyzed
• Report total issues count.
• Commit CSV to branch with message: "Add Coverity analysis report - {issue_count} issues found".
• Announce: Analysis complete. CSV with {N} issues is committed.

---

GLOBAL RULES (STRICT)

• No Python scripts creation
• No skipping files
• Perform detailed per-component analysis
• No batching/merging of components or issues
• Sequential component processing (one at a time, complete before next)
• Incremental CSV building (append as you go)
• Component names must match the analyzed top-level folder/subsystem name exactly; do not rename, split, or merge components
• Do not proceed to the next component until every file in the current component has been fully read and every detected issue has been recorded in the CSV