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

DOCS-9659: Set due date rules #26634

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

Conversation

drichards-87
Copy link
Contributor

What does this PR do? What is the motivation?

New docs for Set due date rules for Vulnerability Pipeline.

Merge instructions

Merge readiness:

  • Ready for merge

Merge queue is enabled in this repo. To have it automatically merged after it receives the required reviews, create the PR (from a branch that follows the <yourname>/description naming convention) and then add the following PR comment:

/merge

Additional notes

@drichards-87 drichards-87 added WORK IN PROGRESS No review needed, it's a wip ;) Do Not Merge Just do not merge this PR :) security Content changed in the security folder labels Dec 5, 2024
@drichards-87 drichards-87 requested a review from a team as a code owner December 5, 2024 19:15
@github-actions github-actions bot added the Architecture Everything related to the Doc backend label Dec 5, 2024
@drichards-87 drichards-87 added editorial review Waiting on a more in-depth review and removed WORK IN PROGRESS No review needed, it's a wip ;) Do Not Merge Just do not merge this PR :) labels Jan 27, 2025
Copy link

@JonRuben JonRuben left a comment

Choose a reason for hiding this comment

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

I'd recommend adding the following:

An explanation of what will remove the due date (rule passing, muted, due date removed)

An explanation of what happens when a rule becomes overdue. And if there's a notification sent when it does. -- Maybe a PM can help you identify what happens? Since I'm not sure.

Specify that the due date is set from the time in which the vuln was discovered, not the time the due date was created

A screenshot of what the due date looks like on the page, since it can be hard to find. I'm not sure if this is what we usually do, but I think it would help the customer a bunch.

## Create a due date rule

1. On the [Automation Pipelines][2] page, click **Add a New Rule** and select **Set Due Date**.
1. Enter a descriptive name for the rule, for example, Cloud Infrastructure Anomaly Warnings.

Choose a reason for hiding this comment

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

Shouldn't there be quotes around "Cloud Infrastructure Anomaly Warnings"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are you required to surround the name in quotes when adding it in the UI?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If you're referring to style conventions, we don't have one for this. But I'd probably lean towards using bold vs. quotes for text that you would enter in a field. I can add that to the PR.

Choose a reason for hiding this comment

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

Definitely don't need it in quotes when adding it to the UI. Bold wuld be better.

@drichards-87
Copy link
Contributor Author

I'd recommend adding the following:

An explanation of what will remove the due date (rule passing, muted, due date removed)

To clarify:

  • Rule passes: If a rule starts passing, the due date no longer applies. That makes sense to me.
  • Muted: If the vulnerability is muted, the due date no longer applies. This could occur if you manually mute the vulnerability, or if it's auto-muted by one of the mute rules, correct?
  • Due date removed: How do you remove a due date? Can you do this manually on a vulnerability that has a due date? Or would this only occur if the due date rule is disabled or deleted?

An explanation of what happens when a rule becomes overdue. And if there's a notification sent when it does. -- Maybe a PM can help you identify what happens? Since I'm not sure.

I'll reach out to Etienne about this.

Specify that the due date is set from the time in which the vuln was discovered, not the time the due date was created

I'll add this to the instructions for adding a due date rule.

@JonRuben
Copy link

JonRuben commented Jan 27, 2025

Muted: If the vulnerability is muted, the due date no longer applies. This could occur if you manually mute the vulnerability, or if it's auto-muted by one of the mute rules, correct?

Correct

Due date removed: How do you remove a due date? Can you do this manually on a vulnerability that has a due date? Or would this only occur if the due date rule is disabled or deleted?

You can only do this if the rule is disabled or deleted

xlamorlette-datadog
xlamorlette-datadog approved these changes Jan 28, 2025
- The detection rule that triggered the vulnerability passes successfully.
- The vulnerability is muted, either manually or automatically through a mute rule.
- The due date rule associated with the vulnerability is disabled or deleted.

Choose a reason for hiding this comment

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

Also, the due date will be removed if the due date rule associated with the vulnerability has been modified and it doesn't match anymore the vulnerability.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, okay, that's good to know. I'll add that to the PR.

xlamorlette-datadog

This comment was marked as duplicate.

1. On the [Automation Pipelines][2] page, click **Add a New Rule** and select **Set Due Date**.
1. Enter a descriptive name for the rule, for example, **Cloud Infrastructure Anomaly Warnings**.
1. Use the following boxes to configure the rule criteria:
- **Any of these types**: The types of findings that the rule should check for. Available types include **Misconfiguration**, **Attack Path**, **Identity Risk**, and **API Security Finding**.

Choose a reason for hiding this comment

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

I believe that "Application Code Vulnerability" and "Application Library Vulnerability" and "Container Image Vulnerability" are also options.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. Do you know where I could see this in the UI? I'm not seeing it in any of the orgs right now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@JonRuben Thanks for the link.

P.S. I deleted your comment as this is a public repo, just to be safe.

@DataDog DataDog deleted a comment from JonRuben Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Architecture Everything related to the Doc backend editorial review Waiting on a more in-depth review security Content changed in the security folder
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants