Skip to main content

End-to-End Workflow

This guide walks through a complete scenario: installing Dike, detecting your first violation, investigating it, and closing it out. By the end, you'll understand how Dike fits into your daily compliance workflow.

The Scenario​

You're a compliance manager at Acme Corp. Your team has 5 developers working across 3 repositories, and you need to demonstrate SOC2 compliance for an upcoming audit. Specifically, you need to prove that:

  • All code changes are linked to authorized work items (Jira issues)
  • All code changes go through pull request review
  • CI/CD checks pass before code reaches production

Let's set up Dike to monitor these requirements.

Step 1: Install and Configure Dike​

Follow the Getting Started guide to:

  1. Install Dike from the Atlassian Marketplace
  2. Connect your GitHub account via OAuth
  3. Install the GitHub App for your organization
  4. Create a Compliance Violations project in Jira

For this scenario, let's say you created a project with key COMPVIOL.

Time: ~15 minutes

Step 2: Enable Compliance Rules​

With Dike installed, head to the Compliance Rules tab. You'll see pre-configured example rules that are disabled by default.

For our SOC2 requirements, enable these rules:

RuleWhat it CatchesSeverity
Commits to main without PRDirect pushes bypassing reviewHigh
PR merged without approvalsInsufficient code reviewHigh
PR merged with failing buildBroken CI/CD gatesHigh
Commit missing issue keyUntracked changesMedium
PR without issue referenceUntracked changesMedium

To enable a rule:

  1. Click the rule to expand it
  2. Change Status from "Disabled" to "Enabled"
  3. Click Save
tip

Start with high-severity rules first. You can enable medium and low severity rules once you've tuned the critical ones.

Time: ~5 minutes

Step 3: Trigger Your First Scan​

Dike scans your repositories automatically, but let's trigger a manual scan to see immediate results.

  1. Go to the Repository Scanning tab
  2. Find one of your repositories (e.g., acme-corp/backend-api)
  3. Click the Rescan button
  4. Watch the progress bar as Dike analyzes commits and PRs

By default, Dike scans the last 365 days of activity. For a typical repository with moderate activity, this takes 1-2 minutes.

Time: ~2 minutes per repository

Step 4: Review Detected Violations​

After the scan completes, you'll likely see some violations. In our scenario, let's say Dike found:

  • 3 commits pushed directly to main without PRs
  • 2 PRs merged without any approvals
  • 5 commits missing Jira issue references

Viewing in Dike​

The Repository Scanning page shows violations grouped by repository. Click any violation to see details:

  • What happened: Commit SHA or PR number
  • When: Timestamp of the violation
  • Why: Which rule was violated
  • Link: Direct link to GitHub

Viewing in Jira​

Each violation also created a Jira issue. Go to your COMPVIOL project or use JQL:

project = COMPVIOL AND status = Open ORDER BY priority DESC

You'll see 10 issues corresponding to the violations found.

Step 5: Investigate a Violation​

Let's investigate one of the high-severity violations: a direct commit to main.

In Jira​

Open the issue. The description shows:

**Violation Type:** Direct commit to protected branch
**Repository:** acme-corp/backend-api
**Branch:** main
**Commit:** abc1234 - "Quick fix for login bug"
**Author:** jsmith
**Date:** 2024-03-15

This commit was pushed directly to main without going through a pull request.

In GitHub​

Click the GitHub link in the description. Review:

  • What code was changed
  • Who made the change
  • Whether it looks malicious or just a process slip

In our scenario, this was a developer who pushed directly during an urgent bug fix, bypassing the normal PR process.

Step 6: Resolve the Violation​

For each violation, you have three paths:

Path A: The Code is Fine, Process Was Bypassed​

If the code change is legitimate but process wasn't followed:

  1. Review the change on GitHub to verify it's not malicious
  2. Talk to the developer about following the PR process
  3. Close the violation in Jira with a comment explaining the resolution: 
    Reviewed commit abc1234. Code change was a legitimate bug fix.
    Discussed proper PR workflow with jsmith to prevent recurrence.

Path B: The Code Needs to Be Fixed​

If the code change introduced problems:

  1. Create a follow-up issue in your main project to fix the problem
  2. Link the violation to the fix issue
  3. Close the violation once the fix is deployed

Path C: False Positive - Adjust the Rule​

If the violation shouldn't have been flagged:

  1. Review your rule configuration - maybe the rule is too broad
  2. Add exclusions for legitimate cases (e.g., certain branches, bots)
  3. Close the violation with a note about the rule adjustment

For our direct-commit violation, we'll follow Path A since the code was fine.

Step 7: Update Violation Status​

In Jira, transition the violation through your workflow:

Open → Acknowledged → Resolved
  1. Acknowledge: Click to indicate you've reviewed the violation
  2. Resolve: Click when the issue is fully addressed

Add comments at each stage documenting your actions. This creates an audit trail.

Step 8: Establish Your Routine​

With Dike running, establish a daily compliance routine:

Daily (5 minutes)​

  • Check for new high-severity violations
  • Acknowledge violations you're working on
  • Close resolved violations

Weekly (15 minutes)​

  • Review medium-severity violation trends
  • Look for patterns (same developer, same repository)
  • Adjust rules to reduce false positives

Monthly (30 minutes)​

  • Run the saved filter for the month's violations
  • Export data for compliance reporting
  • Review metrics: violations found, time to resolution

Ongoing: Automatic Monitoring​

After initial setup, Dike works automatically:

  • Every 5 minutes: Quick check for new activity
  • Every hour: Deep compliance analysis
  • Continuously: New violations create Jira issues automatically

You'll receive notifications (if configured) when new violations are detected.

Preparing for Your SOC2 Audit​

When audit time comes, you'll have evidence showing:

  1. Controls are in place: Dike rules demonstrate your compliance policies
  2. Violations are detected: Historical violations prove monitoring works
  3. Violations are addressed: Resolution history shows you act on findings
  4. Trends improve: Declining violation counts show process maturity

Export your evidence using JQL:

project = COMPVIOL AND created >= "2024-01-01" AND created <= "2024-12-31"

Summary​

The complete Dike workflow:

  1. Install → Connect GitHub → Create violations project
  2. Configure → Enable rules for your compliance requirements
  3. Scan → Trigger initial scan, then rely on automatic monitoring
  4. Review → Check new violations in Jira or Dike dashboard
  5. Investigate → Follow GitHub links, review code changes
  6. Resolve → Fix issues or acknowledge legitimate bypasses
  7. Report → Export data for audits and stakeholders

Next Steps​