Skip to main content

Commits Without Associated Issues

This compliance check detects commits that don't reference a Jira issue in their commit message. Linking commits to issues creates an audit trail connecting code changes to authorized work items.

What It Detects​

Dike scans commit messages for Jira issue key patterns (e.g., PROJ-123). When a commit message lacks a recognizable issue key, it creates a violation.

Examples of commits that trigger violations:

  • Fix login bug (no issue key)
  • Update dependencies (no issue key)
  • Refactor user service (no issue key)

Examples of compliant commits:

  • PROJ-123: Fix login bug
  • [PROJ-456] Update dependencies
  • Refactor user service (PROJ-789)

Two Check Versions​

Dike offers two versions of this check:

  1. Pattern-only check (missing-issue-key-pattern): Searches for issue key patterns using regex (default: [A-Z]+-[0-9]+). This version does not verify whether the issue actually exists in Jira. Use this when your organization has multiple Jira instances and Dike may not have access to all of them.

  2. Issue existence check (missing-issue): Verifies that the referenced issue actually exists in the Jira instance where Dike is installed. This catches typos like PROJ-9999 when that issue doesn't exist, but only works for issues in the connected Jira instance.

Why It Matters for SOC2​

SOC2 compliance requires demonstrating that all system changes are authorized and traceable. This check supports several SOC2 controls:

  • CC6.1 - Change Management: All changes must be authorized and documented. Linking commits to Jira issues proves the change was part of approved work.
  • CC7.1 - System Changes: Organizations must maintain evidence of change authorization. Issue-linked commits create an auditable trail.
  • CC7.2 - Change Tracking: Changes must be tracked throughout their lifecycle. The commit-to-issue link enables tracing from code back to requirements.

Without issue references, auditors cannot verify that code changes were authorized, which can result in compliance gaps during SOC2 audits.

How to Resolve Violations​

  1. Review the commit to verify the changes are not malicious or unauthorized.
  2. Close the violation in Dike once you've confirmed the commit is legitimate.

For commits that are genuinely problematic, consider reverting them and re-applying through proper channels with appropriate issue references.

Preventive Measures​

  • Configure Git hooks: Use a commit-msg hook to validate issue key presence before commits are accepted.
  • Team guidelines: Establish commit message conventions that require issue references.
  • IDE integrations: Many IDEs support commit message templates that include issue key placeholders.

Configuration Options​

Rule Configuration​

name: Commit missing issue key pattern
trigger: commit_pushed
status: enabled
priority: medium
conditions:
  - type: missing-issue-key-pattern
    operator: matches
    value: "[A-Z]+-[0-9]+"
actions:
  - type: create-violation
    severity: medium
branchPatterns: []

Configurable Parameters​

ParameterDescriptionDefault
value (pattern)Regex pattern for matching issue keys[A-Z]+-[0-9]+
severityViolation severity levelmedium
branchPatternsBranches to scan (empty = all branches)[]
statusRule status: enabled, disabled, warningdisabled
priorityRule priority for orderingmedium

Issue Existence Check​

To verify that referenced issues actually exist in Jira (not just match a pattern):

conditions:
  - type: missing-issue
    operator: equals
    value: true

This uses the Jira API to confirm the issue exists. Note that this only validates issues in the Jira instance where Dike is installed. For organizations with multiple Jira instances, use the pattern-only check instead.