🤖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.

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. Dismissals require review: developers may dismiss code risks using Arnica's ChatOps. If this configuration is enabled, developers will be able to suggest a dismissal, but only Arnica's operators will be able to dismiss each code risk individually.

  2. Custom footer messages: Arnica's rules (see Rules section below) can trigger an instant message on Slack or Microsoft Teams, or comment on a pull request. To support developers with further questions, you can add a custom footer to all communications sent to developers.

Static Application Security Testing (SAST)

This section allows customers to configure custom Semgrep rules.

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.

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. Git push: every time a developer pushes code with 1 or more commits, they are analyzed in real-time.

  2. 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, the code will analyze the new HEAD of the source branch.

  3. User created issue: this action is triggered when a user clicks on the Jira issue creation icon in the finding details.

  4. User dismissed finding via ChatOps: We are working towards a goal to make your team more productive and responsive to engineering teams. Therefore, you can configure this trigger to notify when a developer clicked on Dismiss in the ChatOps Integration (e.g. Slack or Microsoft Teams), so that you can respond in a timely manner based on the conditions that are most important for you.

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.

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 the user based on the context of the trigger. When a git push event occurs, Arnica can send a message to the user who authored, committed or pushed the vulnerable code. Arnica can also select the remediation owners as defined in Product Owners.

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

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.

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

PreviousInfrastructure as Code SecurityNextDeveloper Feedback On Push

Last updated