🤖Code Risk Policy Settings

Overview

Arnica's policies unlock the power of real-time code risk scanning and ChatOps utilization as part of the developers' day to day work. This section will highlight the different capabilities of the policy, guide you on setting up the policies, and provide insights into the most common policies used by Arnica's customers.

Policy structure

All policies can be configured in the Policies page. These policies are comprised of general configurations and event-driven behavior.

Code Risk policy section in the Policies page

Configurations

The configurations are the advanced settings that each customer can tweak across the tenant.

General

This section contains the settings that are applicable for all code risks:

1. Custom instant message footer: add a Markdown-enabled footer to ChatOps messages sent via Slack or Microsoft Teams.

2. Custom pull request (PR) comment footer: add a Markdown-enabled footer to PR comments posted by Arnica.

3. Dismissals always require review: if enabled, developers can suggest dismissals, but operators must review before dismissal is finalized (see Require Review Before Dismissal).

General configuration section in the Code Risk policy

Static Application Security Testing (SAST)

This section allows customers to configure custom SAST rules and enable or disable default SAST detections.

Licenses

Arnica automatically classifies licenses based on Google's open source guidance. This policy configuration enables operators to override license classifications and their associated risk levels.

Software Composition Analysis (SCA)

This section includes package risk settings for SCA, including whether to include pre-release package versions (alpha, beta, rc, etc.).

Dismissals

The dismissals configuration controls whether dismissals always require operator review.

AI SAST Execution Conditions

This section controls where AI SAST agents run: On Push, On Pull Request, and On Routine Scan. You can also configure the global prompt via the AI Configuration page and product-level prompts via the Products page.

Rules

Arnica's rules are executed when triggers are configured, such as git push or pull request creation. The identification of the code risks is scoped with specific conditions, such as a specific code repository with at least high severity vulnerability. When these conditions are met, Arnica executes the selected actions, such as sending an instant message to the code pusher.

By default, Arnica's policy uses a git push trigger with a condition that is always "true" and has no associated actions.

Triggers

The supported triggers are:

1. Code risk detected on push: every time a developer pushes code with 1 or more commits, they are analyzed in real-time.

2. Code risk detected on pull request: every time a pull request is created, the HEAD of the source branch is scanned. In addition, if the source branch is updated with new commits, Arnica analyzes the new HEAD of the source branch.

3. Code risk resolved on pull request: triggered when previously fixed code risks are included in a pull request.

4. Code risk detected during a routine scan: triggered when a routine scan identifies a code risk.

5. Code risk detected from a container scan: triggered when a container scan identifies a code risk.

6. User created issue: triggered when a user manually creates an issue from a finding (see Jira integration mapping).

7. User dismissed finding via ChatOps: triggered when a user clicks Dismiss in ChatOps (Slack or Microsoft Teams), so operators can respond quickly based on policy conditions.

8. Code risk detected during an API initiated SBOM scan: triggered when an API-initiated SBOM scan identifies a code risk.

9. Pull request created: triggered when a pull request is created.

Trigger picker in the current Code Risk policy UI

Conditions

The supported conditions are:

1. Always (TRUE): This condition will always evaluate to true. A good use of this policy is to see all real-time results as developers push code.

2. Any of (OR): a logical operator that is set to true if any of the sub-conditions (any of the conditions on this list) are matched in the context of the executed trigger.

3. All of (AND): a logical operator that is set to true if all of the sub-conditions (any of the conditions on this list) are matched in the context of the executed trigger.

4. Reverse (NOT): this condition allows to negate a specific sub-condition (consider false if the sub-condition is true and vice versa).

5. Source Code Management: if multiple source code management platforms are integrated into Arnica, such as Github and Azure DevOps, a specific platform can be selected.

6. Organization: if multiple organizations or workspaces are integrated, this condition can select a specific organization.

7. Project: the condition allows to select a specific project in the organization. Note: this only applies to SCMs with project hierarchy. If the SCM does not support a project hierarchy, the condition will always return true.

8. Repository: the condition allows to select a specific source code repository.

9. Branch: the condition allows to select the impacted branch (regular expression) of the triggered event. In case of a pull request trigger, the branch is matched against the source branch (where the vulnerability is introduced).

10. Product: the condition allows to select a specific product as defined in Product Owners.

11. File Path: the condition allows to specify a regular expression of the path. It is useful when different actions should be taken based on different paths in the same repository, such as in mono-repos.

12. Severity: selects the minimum risk severity of a finding. For example, if all risks with a medium severity and above should be matched against this condition, select "Medium" only.

13. Finding Type: the supported finding types are IaC, License, Reputation, SAST and SCA.

14. Exceeded SLA (pull request triggers only): Arnica kicks off an SLA when code risks are merged into a default branch or when they are detected in the scheduled jobs. SLA is counted between the first detection date and the current date - this rule will be matched in case the defined number in the condition is smaller than the difference in days between these two.

15. SAST Rule ID: the condition allows to specify a list of regular expressions with SAST rule identifiers, which can be found in each SAST finding.

16. SCA Finding Has a Fix: SCA findings may not have a fix, mainly due to not having a fixed version available, but also when the used package is internal. This condition matches only SCA findings with a fix available.

17. Repository Business Importance: filters findings by the selected repository business-importance level.

18. Topic: filters findings by the selected repository/topic metadata.

19. Product Business Importance: filters findings by the selected product business-importance level.

20. Has product matching labels: matches findings in products that have the selected labels.

21. Git Blame Property: matches findings by git blame metadata using provided expressions.

22. SAST Property: matches findings by SAST metadata using provided expressions.

23. Is AI SAST: matches findings detected by AI SAST.

24. Package Name and Version: matches findings by package name/version expressions.

25. Package Manager: matches findings by selected package manager.

26. Package Release Date: matches findings by package release date range.

27. Latest Version Release Date: matches findings by latest package release date range.

28. CVSS Score: matches findings by CVSS score thresholds/ranges.

29. EPSS Score: matches findings by EPSS score thresholds/ranges.

30. Has KEV: matches findings based on Known Exploited Vulnerability (KEV) status.

Condition picker showing asset, product, finding, SAST, package, and SCA options

Actions

Actions are unique per trigger and can be executed only when the conditions within the policy rule are met.

For a git push trigger, Arnica can send instant messages to one or more of the following:

1. Recipient(s) lookup: Arnica can lookup users based on the trigger context. For push-based rules, common recipient lookups include Code Pusher and Code Author. Arnica can also select remediation owners as defined in Product Owners.

2. Specific recipient: Arnica can send a direct message to a user or channel.

Example action recipients in a push-based Code Risk rule

If the instant messaging channel doesn't appear in the specific recipients list, invite the bot named arnica to your channel on Slack or team on Microsoft Teams.

An example of an instant message notification can be found in the Developer Feedback on Push page.

When a pull request trigger is configured in the policy, Arnica can do the following:

1. Send an instant message, similarly to the description in the git push trigger above.

2. Comment on pull request: Arnica can add a comment inline with the code (similarly to comments in a code review) or as separate comments in the PR. The location of the comment depends on the conditions - see the different scenarios in 0 New High Severity Vulnerabilities and Enforce Remediation SLA pages. Additionally, Arnica can mention specific members in the relevant messages - select the mention a user or a group checkbox and add the relevant members similarly to the description in the git push trigger above.

3. Fail status check: Arnica creates a full report of all outstanding findings on every status check execution. If there are no outstanding findings, the status check will succeed. Otherwise, Arnica will fail the status check.

Product-mapped actions at enterprise scale

Product Mapped actions let one policy dynamically route workflows by product/team ownership instead of hard-coding one static destination.

• Create Issues (Product Mapped): routes findings to team-specific ticketing configurations (project, required fields, and workflow mapping) based on the matched product.

• Send Instant Message (Product Mapped): routes notifications to the right people/channels for each product, so the correct team is engaged automatically.

Example:

• Team X findings can be routed to Jira project ABC with Team X-specific fields/workflow.

• Team Y findings can be routed to Jira project DEF with different fields/workflow.

• The same single policy can also notify different people/channels dynamically per product mapping.

This is a powerful way to scale governance across the enterprise while keeping policy management centralized.

Action picker for a push-triggered rule

Comment on Pull Request action fields include:

• Mention a user or a group

• Dismissals require review

• Include AI-powered code suggestion

PR comment action fields in a pull request trigger rule

Arnica doesn't block pull request merges by default (a.k.a. "soft" security gate). To enforce the block (a.k.a. "hard" security gate) follow the "view unenforced branches" link in the policy and then select the relevant repositories and branches.

More information about the Create Issue action can be found in the Jira Integration page.

Rules execution order

Customers are encouraged to define multiple rules. The rules in the policy are executed in order - if there is a match in the trigger and conditions, Arnica will execute the action and stop processing other rules.

To better illustrate how rules are executed, consider the following example. Assume the following rule definitions:

• Rule #1: Notify developers on Medium severity in the product "GitGoat"

  • Trigger: git push

  • Conditions: All of (severity = medium, project = GitGoat)

  • Actions: send instant message to a recipient lookup of the code pusher

• Rule #2: Comment on pull request and fails status check if the developer introduced new Medium severity security vulnerabilities in a feature branch in the project "GitGoat", and tag the relevant remediation owners

  • Trigger: pull request

  • Conditions: All of (severity = medium, project = GitGoat)

  • Actions: comment on pull request and mention a user or a group with the mention lookup of product owners and fail status check.

• Rule #3: Notify the security team on Critical severity vulnerabilities in pull requests

  • Trigger: pull request

  • Conditions: severity = critical

  • Actions: send instant message to a specific recipient with the name #security-channel.

The following scenarios will be handled by the specific rule numbers above:

• A High severity vulnerability is pushed to a feature branch in the product GitGoat -> Rule #1.

• A High severity vulnerability is pushed to a feature branch in any product other than GitGoat -> No match.

• A new Medium severity vulnerability is identified in the source branch in the product "GitGoat" -> Rule #2.

• A new High severity vulnerability is identified in the source branch in any product other than "GitGoat" -> No match.

• A new Critical severity vulnerability is identified in the source branch in the product "GitGoat" -> Rule #2 (it matches Rule #3 as well, but the processing stops beforehand).

• A new Critical severity vulnerability is identified in the source branch in a product other than "GitGoat" -> Rule #3.

Policy considerations

Detect on git push, then on pull requests

Developers open pull requests when a bulk of functionality is ready for review. Many commits tend to be pushed before the pull request is opened, which means that the code author may no longer have the context of the specific changes in the feature branch, or it may be too late to change. Therefore, it is worth considering sending an instant message to the author if a new vulnerability is introduced. If there is no response on the event, flag the remaining issues in the pull request in comments and status checks.

Refine Conditions and Actions

Certain products may have a higher business importance than others. Arnica's policy supports granular conditions to support the different needs for each product. For example, a product with high business importance may implement 0 new high severity vulnerabilities policy and enforce remediation SLAs, while less important products may have less strict policy.

Additional example of a use case we observed is with the legal team, which might be interested in reviewing risky 3rd party package licenses. Since legal teams typically don't interact with the source code management platform, narrow down the conditions to the specific findings types and add actions to send instant messages to the legal team.

Cleanup code risks exceeded SLA before enabling condition

Arnica can comment on pull requests with the outstanding code risks that exceeded SLA, alongside other conditions. In some cases, the condition may catch too wide set of findings, which may cause unnecessary confusion by the pull request reviewers. Therefore, it is recommended to ensure that all issues in the default branch are reviewed before applying such policy.

Common use cases

Provide developer feedback on push

Require review before dismissal

0 new high severity vulnerabilities

Enforce remediation SLA