Community
Questions Library
Docs
Blog
Events
Swag
Github
Slack
JupiterOne
Discussions
Release Notes
Detect Suspicious Code Commits in Pull Requests - AskJ1 Community
<main> <article class="userContent"> <p>Security of software development and code is more important than ever. JupiterOne can detect suspicious code commits and git behavior in Bitbucket and GitHub pull requests (PRs). For example:</p> <ul><li>Commits self-approved by the code author</li> <li>Commits made by a user unknown to the organization</li> <li>Rewritten commit history</li> </ul><h2 data-id="enable-detection">Enable Detection</h2> <p>For the detection to work, you will need to:</p> <ul><li><p>Enable Pull Request (PR) and commit analysis in the integration configuration in JupiterOne. This is automatically enabled for GitHub integrations but must be explicitly turned on in Bitbucket integrations.</p></li> <li><p>Configure branch permissions in your git source control system to prohibit directly committing to the main branch (e.g. <code class="code codeInline" spellcheck="false" tabindex="0">master</code>) and to require pull request reviews before merging.</p> <p>This option is typically found under the repo settings. This allows PR analysis to catch the suspicious activities.</p></li> </ul><p>When enabled, JupiterOne sets the <code class="code codeInline" spellcheck="false" tabindex="0">approved</code>, <code class="code codeInline" spellcheck="false" tabindex="0">validated</code>, and <code class="code codeInline" spellcheck="false" tabindex="0">approvedCommitsRemoved</code> flags on each merged PR entity.</p> <p>You can run a J1QL query to detect "PRs with suspicious activities":</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">Find PR with approved = false or validated = false </pre> <p><img src="https://us.v-cdn.net/6035534/uploads/0VBEFH0KQ0E4/graph-suspicious-pullrequests.png" alt="" class="embedImage-img importedEmbed-img"></img></p> <p>You can also set up an alert with the above query. You can also integrate this analysis into your DevOps pipeline to check for suspicious commits in PRs before deploying code to production.</p> <h2 data-id="how-does-it-work">How does it work?</h2> <h3 data-id="detecting-self-approved-commits">Detecting self-approved commits</h3> <p>At the time of integration execution, or when requested via the API, JupiterOne will analyze the activities on a PR to determine if there is any code commit on the PR that was not approved by someone other than the code author.</p> <p><em>Isn't this already configured via branch protection/permissions?</em></p> <p>Consider the following scenario:</p> <ul><li>Bob writes some code and commits them to a feature branch</li> <li>Bob opens a PR with those changes and requests review from Alice</li> <li>Alice makes another commit to the same branch and updates the PR</li> <li>Alice approves the PR</li> </ul><p>The PR is considered approved by a reviewer because Bob opened the PR and Alice reviewed it. However, Alice technically approved her own code associated with the commit she made to the branch after Bob opened the PR.</p> <p>JupiterOne will detect this condition a sets the <code class="code codeInline" spellcheck="false" tabindex="0">approved</code> flag on the PR entity to <code class="code codeInline" spellcheck="false" tabindex="0">false</code>.</p> <p>The commit hash of the detected suspicious commit is added to the <code class="code codeInline" spellcheck="false" tabindex="0">commitsNotApproved</code> list property.</p> <h3 data-id="detecting-commits-by-unknown-external-authors">Detecting commits by unknown/external authors</h3> <p>Additionally, JupiterOne checks the commit author against known users that are part of your organization. If a commit was made by an unknown/external author, JupiterOne sets the <code class="code codeInline" spellcheck="false" tabindex="0">validated</code> flag on the PR entity to <code class="code codeInline" spellcheck="false" tabindex="0">false</code>.</p> <p>The commit hash of the detected suspicious commit is added to the <code class="code codeInline" spellcheck="false" tabindex="0">commitsByUnknownAuthor</code> list property.</p> <h3 data-id="detecting-rewritten-history">Detecting rewritten history</h3> <p>JupiterOne will check commits going in to master to ensure that they're approved, regardless of Bitbucket's or GitHub's approval statuses. This means that rewriting history in a way that invalidates previous approvals (for example, squash merging) is flagged by setting the <code class="code codeInline" spellcheck="false" tabindex="0">approved</code> property to <code class="code codeInline" spellcheck="false" tabindex="0">false</code> and the <code class="code codeInline" spellcheck="false" tabindex="0">approvedCommitsRemoved</code> property to <code class="code codeInline" spellcheck="false" tabindex="0">true</code>.</p> <p>If you still want to squash merge for a beautiful git history, but also want to avoid merging commits into master that are not explicitly approved, you can rebase before having your code approved and then merge normally.</p> <h2 data-id="combine-suspicious-commits-checking-and-vulnerability-checking-for-ci-cd">Combine suspicious commits checking and vulnerability checking for CI/CD</h2> <p>You can use the following J1QL query to detect open vulnerability findings that are associated with certain code repos, and use this in conjunction with the PR analysis query previously discussed to make automated decisions for promoting code to production in your CI/CD pipeline.</p> <p>For example, you can query JupiterOne via API for:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">Find Finding with open=true and severity=('Critical' or 'High') that relates to CodeRepo with name='my-new-project' Find PR with id=55 as PR that relates to CodeRepo with name='my-new-project' return PR.approved, PR.validated </pre> <p>And block production deploy if the first query above returns a finding or if the second query returns <code class="code codeInline" spellcheck="false" tabindex="0">false</code> for <code class="code codeInline" spellcheck="false" tabindex="0">approved</code> or <code class="code codeInline" spellcheck="false" tabindex="0">validated</code> status.</p> </article> </main>
.png)