Sharang ParnerkarandClaude Opus 4.8
5ad9d2d77c
CI / Check (push) Skipped
CI / Detect Changes (pull_request) Skipped
CI / Deploy Agent (pull_request) Skipped
CI / Deploy Dashboard (pull_request) Skipped
CI / Deploy Docs (pull_request) Skipped
CI / Deploy MCP (pull_request) Skipped
CI / Check (pull_request) Failing after 1m55s
The product is renamed Certifai -> Prüfwerk. This changes only the user-facing brand text in the documentation (docs/**, VitePress title/name). It does NOT touch functional identifiers that happen to contain "certifai" (the Docker network, Keycloak realm/client, Harbor image project, the compliance-* crate names, or the repo name) — those are infra-coupled and need a separate, coordinated migration. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EgxGHn22YEfQz5fLHSHkLv
57 lines
2.8 KiB
Markdown
57 lines
2.8 KiB
Markdown
# Issues & Tracking
|
|
|
|
Prüfwerk automatically creates issues in your existing issue trackers when new security findings are discovered. This integrates security into your development workflow without requiring teams to check a separate tool.
|
|
|
|
## How Issues Are Created
|
|
|
|
When a scan discovers new findings, the following happens automatically:
|
|
|
|
1. Each new finding is checked against existing issues using its fingerprint
|
|
2. If no matching issue exists, a new issue is created in the configured tracker
|
|
3. The issue includes the finding title, severity, vulnerability details, file location, and a link back to the finding in Prüfwerk
|
|
4. The finding is updated with a link to the external issue
|
|
|
|
This means every actionable finding gets tracked in the same system your developers already use.
|
|
|
|
## Issues List
|
|
|
|
Navigate to **Issues** in the sidebar to see all tracker issues across your repositories.
|
|
|
|
|
|
|
|
The issues table shows:
|
|
|
|
| Column | Description |
|
|
|--------|-------------|
|
|
| Tracker | Badge showing GitHub, GitLab, Gitea, or Jira |
|
|
| External ID | Issue number in the external system |
|
|
| Title | Issue title |
|
|
| Status | Open, Closed, or tracker-specific status |
|
|
| Created | When the issue was created |
|
|
| Link | Direct link to the issue in the external tracker |
|
|
|
|
Click the link to go directly to the issue in your tracker.
|
|
|
|
## Supported Trackers
|
|
|
|
| Tracker | How to Configure |
|
|
|---------|-----------------|
|
|
| **GitHub Issues** | Set up in the repository's issue tracker settings with your GitHub API token |
|
|
| **GitLab Issues** | Set up with your GitLab project ID, instance URL, and API token |
|
|
| **Gitea Issues** | Set up with your Gitea repository details, instance URL, and API token |
|
|
| **Jira** | Set up with your Jira project key, instance URL, email, and API token |
|
|
|
|
Issue tracker configuration is per-repository. You set it up when [adding or editing a repository](/guide/repositories#configuring-an-issue-tracker).
|
|
|
|
## Deduplication
|
|
|
|
Issues are deduplicated using the same fingerprint hash that deduplicates findings. This means:
|
|
|
|
- If the same vulnerability appears in consecutive scans, only one issue is created
|
|
- If a finding is resolved and then reappears, the platform recognizes it and can reopen the existing issue rather than creating a duplicate
|
|
- Different findings (even if similar) get separate issues because their fingerprints differ based on file path, line number, and vulnerability type
|
|
|
|
## Linked Issues in Finding Detail
|
|
|
|
When viewing a [finding's detail page](/guide/findings#finding-detail), you will see a **Linked Issue** section if an issue was created for that finding. This provides a direct link to the external tracker issue, making it easy to jump between the security context in Prüfwerk and the development workflow in your tracker.
|