New Feature: One-Click Risk Mitigations

Why we built it

Addressing operational and security risks that exist in developer tools and code repositories is challenging. As a result, operators faced with mitigating these types of risks often deprioritize them due to their complexity or the chance that they will make a mistake in mitigating them. Those mistakes, when made, create even more work as teams must now address both the error and the original issue. Not just a dashboard  

And while all security tools aim to identify risks within their focus area, most tools either stop there or create tickets (read: laundry lists) for tracking the issues that are identified. Maybe they provide steps to find the risk and fix it elsewhere, but rarely do they resolve the risk proactively from within the tool itself.  

At Arnica, we aim to attach each risk that we surface with one-click mitigation.

What did we build?  

In order to do this, Arnica built rich integrations into existing software supply chain tools, giving us the ability to identify and mitigate risks where they exist.  

If we find it, we fix it

When we set out to build Arnica, we had a number of outcomes in mind for our users:  

• Eliminate the need to deeply understand a completely new problem space in order to mitigate a risk within that problem space  
• Reduce work hours associated with manual access reviews, issue triage, and resolution architecting  
• Ensure all mitigations are applied consistently, using the same industry best practices by all admins  
• Minimize risks associated with system governance through instant one-click reversals – reinstating exact pre-mitigation settings

Examples:

A developer has write-access to a repository that she has not pushed code to in 90 days. Arnica will automatically reduce permissions to least-privilege. Should that developer need permissions to this repository in the future, they can request permissions by typing /arnica into Slack, using the Arnica bot. Based on the policy set within Arnica and the context of the request, permissions will either be automatically granted or flagged for manual review.  

A developer account submits a PR with a coding style that does not match their standard patterns. Arnica will identify the anomalous code or developer behavior and notify the author (or manager, depending on policy) that an anomaly has been detected. Arnica will ask the author (or manager) to attest to whether the PR was in fact submitted by them, or not adding an additional factor of authentication.  

A secret is identified in a pull request. Arnica will freeze the PR that was submitted with an identified secret and clone the PR in a new branch with that secret removed. Then Arnica will send the committing developer a Slack message letting them know that a secret was detected in their code and giving them the option to push the cloned PR (without the secret) and delete the previous PR (with the secret).