🥕Secrets Policy Settings

Overview

Arnica's policies unlock the power of real-time code risk scanning and leverage ChatOps to seamlessly integrate into the developers' day to day work. This section will highlight the different capabilities of the secrets policy and guide you in setting up the policies.

Policy structure

All policies can be configured in the Policies page. These policies are comprised of general configurations and policy rules. General settings and policy rules come with default configurations that govern out of the box event-driven behavior.

Configurations

The configurations section provides advanced settings that each customer can change. These configurations take effect across the tenant, and will be applied to all defined secret scanning rules.

Custom Secrets

Customers with proprietary hardcoded secrets can configure custom hardcoded secret detection patterns.

To add custom secrets, click on add in the Custom Secrets section in the secrets category and then add the secret regex in a go compilable format. Modify the risk severity and name you want to appear in each finding and click on save.

Custom secrets policy configuration

A good resource to test your go compatible regular expressions would be https://regex101.com/. Pick the golang flavor on the left side bar and tweak your regular expressions as needed.

Ignored paths

Arnica comes pre-configured with default paths and files that are being excluded from scanning to reduce the false positives rate. These paths are known to produce a high false positive rate based on common repository forks and example paths.

To add a custom ignore path, click on add, provide a go compilable regular expression, pick a name and click on save.

Pre-configured ignored paths

You can use the toggle on the left side of each entry to activate or deactivate each path.

Rules

Arnica's rules are executed when triggers are configured, such as git push event. The identification of the code risks is scoped with specific conditions, such as a specific code repository with at least high severity risk. When these conditions are met, Arnica executes the selected actions, such as sending an instant message to the code pusher and mitigating the secret via git reset.

By default, Arnica's realtime secrets detection policy is disabled. Use this guide to configure the policy rules according to your needs.

Triggers

The only supported trigger for the hardcoded secrets functionality is git push. Every time a developer pushes code with 1 or more commits, they are analyzed in real time.

Arnica does not support secrets scanning on pull requests by design. If the hardcoded secret has been pushed and included in a pull request, an adversary with access to the git history can potentially exploit them. This can be prevented by acting before the pull request is created. Hence, Arnica's secrets mitigation functionality is focused on immediate response to such incidents.

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): allows you 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 be used to select a specific organization.

7. Project: allows the selection of 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: allows the selection of a specific source code repository.

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

10. Product: allows the selection of a specific product as defined in Product Owners.
11. Severity: selects the minimum risk severity of a finding. In this case, only valid or custom secrets will have a severity.
12. Secret Validation Status: allows the selection of a specific type of secret validation.

Actions

Actions are executed only when the conditions within the policy rule are met.

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 hardcoded secret. 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. For example, a common use case is to send notifications to shared security teams upon identification of hardcoded secrets based on given conditions.

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. The Arnica bot can only be invited to private channels.

An example of an instant message notification can be found in the real-time secret mitigations page.

Additionally, Arnica can mitigate hardcoded secrets for the developer, as described in more detail in the git reset mitigation section.

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 actions listed for that rule 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 and the security team on High severity in the product "GitGoat" and mitigate the hardcoded secret

  • Trigger: git push

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

  • Actions: send instant message to a recipient lookup of the code pusher, send a notification to a specific recipient with the name #security-channel, and git reset

• Rule #2: Notify the developer on any valid secret

  • Trigger: git push

  • Conditions: secret validation status = valid

  • Actions: send instant message to the code pusher

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

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

• A High severity valid hardcoded secret is pushed to a feature branch in any product other than GitGoat -> Rule #2.

• A High severity hardcoded secret that is a custom secret is pushed to a feature branch in any product other than GitGoat -> No match. Reason is that custom secret validation status is None.

• A Medium severity valid hardcoded secret is identified in the feature branch in the product "GitGoat" -> Rule #2.