chore(openapi): [main] update client/openapi/trustd.yaml - #1187
chore(openapi): [main] update client/openapi/trustd.yaml#1187trustify-ci-bot[bot] wants to merge 2 commits into
Conversation
Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Reviewer's GuideUpdates the trustd OpenAPI spec to version 0.6.0-rc.1, adding Exploit Intelligence job APIs and related schemas, plus NVD importer/advisory support. Sequence diagram for Exploit Intelligence job lifecycle APIssequenceDiagram
actor Client
participant trustd_api
Client->>trustd_api: analyzeExploitIntelligence(AnalyzeRequest)
trustd_api-->>Client: AnalyzeResponse (201 or 200)
Client->>trustd_api: listExploitIntelligenceJobs(q, sort, offset, limit, total)
trustd_api-->>Client: PaginatedResults_ExploitIntelligenceJobSummary
Client->>trustd_api: getExploitIntelligenceJob(id)
trustd_api-->>Client: ExploitIntelligenceJobDetails (200 or 404)
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- The
qparameter description and examples for/api/v3/exploit-intelligence/jobsreference advisories and fields liketitle/modifiedthat don't match the allowed fields (id,sbom_id,vulnerability_id,status,created,updated); consider updating this text to align with the actual schema for jobs. - For timestamp properties like
createdandupdatedacross the new Exploit Intelligence schemas, consider adding an explicitformat: date-timeto make the expected value more precise for clients and tooling. - The
PaginatedResults_ExploitIntelligenceJobSummary.itemsschema inlines the job summary structure instead of referencingExploitIntelligenceJobSummary; reusing the existing component via$refwould reduce duplication and keep the definitions consistent.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `q` parameter description and examples for `/api/v3/exploit-intelligence/jobs` reference advisories and fields like `title`/`modified` that don't match the allowed fields (`id`, `sbom_id`, `vulnerability_id`, `status`, `created`, `updated`); consider updating this text to align with the actual schema for jobs.
- For timestamp properties like `created` and `updated` across the new Exploit Intelligence schemas, consider adding an explicit `format: date-time` to make the expected value more precise for clients and tooling.
- The `PaginatedResults_ExploitIntelligenceJobSummary.items` schema inlines the job summary structure instead of referencing `ExploitIntelligenceJobSummary`; reusing the existing component via `$ref` would reduce duplication and keep the definitions consistent.
## Individual Comments
### Comment 1
<location path="client/openapi/trustd.yaml" line_range="4862-4871" />
<code_context>
message:
type: string
description: A human-readable error message
+ ExploitIntelligenceFinding:
+ type: string
+ description: |-
+ Analysis finding from the Exploit Intelligence service.
+
+ Represents the outcome of a vulnerability analysis for a given component/CVE pair.
+ enum:
+ - vulnerable
+ - not_vulnerable
+ - uncertain
+ ExploitIntelligenceJobDetails:
+ type: object
</code_context>
<issue_to_address>
**nitpick:** Descriptions for component count fields reference capitalized finding names that don't match the enum values.
The `ExploitIntelligenceFinding` enum uses lowercase values (`vulnerable`, `not_vulnerable`, `uncertain`), but the `*_components` field descriptions reference `NotVulnerable`, `Vulnerable`, and `Uncertain`. Please update the descriptions to match the enum values (e.g., "components with `finding=not_vulnerable`") to avoid ambiguity for clients.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| ExploitIntelligenceFinding: | ||
| type: string | ||
| description: |- | ||
| Analysis finding from the Exploit Intelligence service. | ||
|
|
||
| Represents the outcome of a vulnerability analysis for a given component/CVE pair. | ||
| enum: | ||
| - vulnerable | ||
| - not_vulnerable | ||
| - uncertain |
There was a problem hiding this comment.
nitpick: Descriptions for component count fields reference capitalized finding names that don't match the enum values.
The ExploitIntelligenceFinding enum uses lowercase values (vulnerable, not_vulnerable, uncertain), but the *_components field descriptions reference NotVulnerable, Vulnerable, and Uncertain. Please update the descriptions to match the enum values (e.g., "components with finding=not_vulnerable") to avoid ambiguity for clients.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1187 +/- ##
=======================================
Coverage 54.09% 54.09%
=======================================
Files 250 250
Lines 5638 5638
Branches 1748 1748
=======================================
Hits 3050 3050
Misses 2331 2331
Partials 257 257
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The openapi.yaml of trustify has changed
Summary by Sourcery
Update Trustd OpenAPI specification for the new release, adding Exploit Intelligence APIs and NVD support.
New Features:
Enhancements: