-
Feature Request
-
Resolution: Duplicate
-
Undefined
-
None
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
- Proposed title of this feature request
2. What is the nature and description of the request?
3. Why does the customer need this? (List the business requirements here)
4. List any affected packages or components.
Customers want to integrate the results from ACS policies (typically vulnerability policies) into external tools.
For general policies, they are often querying the API /v1/alerts, or using Webhooks or other integrations to push violation data to an external system.
A challenge with this pattern is that changes to violations over time are not easily queried in the API, and do not trigger additional notifications. A violation can change in a few situations:
- A violation can be removed because the Deployment was deleted.
- The conditions that caused the policy criteria to match are no longer true, and the violation state is changed to resolved. (also note that "Violation State" isn't easy to determine in the UI)
- For violations on vulnerabilities, new vulnerabilities matching policy criteria are added to any existing violations for that policy, for that deployment.
- For runtime violations, new process activity for the same policy, for that deployment, are added to existing violations. e.g., multiple invocations of "apt" over time get added to the Violation for Package Manager Execution for that Deployment
- For "Unauthorized Process Execution," additional process activity is added to the violation, with a limit of 40 process entries.
For vulnerabilities, customers are using the above API / webhook, but are also querying /v1/images or "roxctl image scan" output.
Challenges with this pattern:
- Querying all images for all of their components and vulnerabilities is a lot of data. The output can be parsed to determine what has changed since the last scan / query, but this requires retrieving all of the JSON data and post-processing it.
- Sending filters to the backend to reduce the amount of data returned (e.g., Active images only) is difficult / impossible.
- Not possible to query for the status of a particular CVE/Deployment pair independent of other results.
- Not possible to filter based on "new CVEs since timestamp xxxx-yy-zz:00"
Customers seek a way to get updates on existing issues to keep their external systems in sync.
Some possible solutions:
- Notifications that "fire" on updates to a Violation
- Option to push notifications upon changes to a Violation
- Immutable violations; new policy criteria matches result in a new Violation
- API endpoints that accept filters to reduce the amount of data sent
- is duplicated by
-
RFE-7631 [RHACS]: Streaming API endpoint for v1/alerts
-
- Approved
-