docs: rebrand Certifai → Prüfwerk (user-facing name) #243
@@ -2,7 +2,7 @@ import { defineConfig } from 'vitepress'
|
||||
import { withMermaid } from 'vitepress-plugin-mermaid'
|
||||
|
||||
export default withMermaid(defineConfig({
|
||||
title: 'Certifai',
|
||||
title: 'Prüfwerk',
|
||||
description: 'AI-powered security compliance scanning platform',
|
||||
ignoreDeadLinks: [
|
||||
/localhost/,
|
||||
@@ -54,7 +54,7 @@ export default withMermaid(defineConfig({
|
||||
{ icon: 'github', link: 'https://gitea.meghsakha.com/sharang/compliance-scanner-agent' },
|
||||
],
|
||||
footer: {
|
||||
message: 'Certifai Documentation',
|
||||
message: 'Prüfwerk Documentation',
|
||||
},
|
||||
},
|
||||
mermaid: {},
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# MCP Integration
|
||||
|
||||
Certifai exposes your security data through the Model Context Protocol (MCP), allowing LLM-powered tools to query your findings, SBOM data, and DAST results directly.
|
||||
Prüfwerk exposes your security data through the Model Context Protocol (MCP), allowing LLM-powered tools to query your findings, SBOM data, and DAST results directly.
|
||||
|
||||
## What is MCP?
|
||||
|
||||
The Model Context Protocol is an open standard that lets AI tools (like Claude, Cursor, or custom agents) connect to external data sources. Think of it as a way for your LLM to "see" your security data without you having to copy and paste it.
|
||||
|
||||
When an MCP client is connected to Certifai, you can ask questions like "Show me all critical findings" or "What vulnerable packages does this repo have?" and the LLM will query Certifai directly to get the answer.
|
||||
When an MCP client is connected to Prüfwerk, you can ask questions like "Show me all critical findings" or "What vulnerable packages does this repo have?" and the LLM will query Prüfwerk directly to get the answer.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
@@ -60,13 +60,13 @@ The MCP server exposes seven tools that LLM clients can discover and call:
|
||||
|
||||
## Connecting an MCP Client
|
||||
|
||||
To connect an MCP-compatible tool (like Claude Desktop or Cursor) to your Certifai MCP server:
|
||||
To connect an MCP-compatible tool (like Claude Desktop or Cursor) to your Prüfwerk MCP server:
|
||||
|
||||
1. Go to **MCP Servers** in Certifai and note the server endpoint URL and access token
|
||||
1. Go to **MCP Servers** in Prüfwerk and note the server endpoint URL and access token
|
||||
2. In your MCP client, add a new server connection with:
|
||||
- **URL** -- the MCP server endpoint (e.g. `https://your-certifai-instance/mcp`)
|
||||
- **URL** -- the MCP server endpoint (e.g. `https://your-pruefwerk-instance/mcp`)
|
||||
- **Transport** -- Streamable HTTP
|
||||
- **Authentication** -- Bearer token using the access token from Certifai
|
||||
- **Authentication** -- Bearer token using the access token from Prüfwerk
|
||||
|
||||
Once connected, the LLM client automatically discovers the available tools and can call them in response to your questions.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Demo Targets
|
||||
|
||||
Certifai ships a small, versioned set of **demo targets** — representative
|
||||
Prüfwerk ships a small, versioned set of **demo targets** — representative
|
||||
inputs that exercise every scan path repeatably. They double as the fixture
|
||||
set for the nightly regression and as a ready-made walkthrough for demos.
|
||||
|
||||
|
||||
@@ -116,7 +116,7 @@ When you mark a finding as a false positive, you are providing training signal t
|
||||
|
||||
## Human in the Loop
|
||||
|
||||
Certifai uses AI to triage findings, but humans make the final decisions. Here is how the process works:
|
||||
Prüfwerk uses AI to triage findings, but humans make the final decisions. Here is how the process works:
|
||||
|
||||
1. **AI triages** -- the LLM reviews each finding, assigns a severity, generates a confidence score, and writes a rationale explaining its assessment
|
||||
2. **You review** -- you read the AI's analysis alongside the code evidence and decide whether to act on it
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Getting Started
|
||||
|
||||
Certifai is an AI-powered security compliance platform that scans your Git repositories for vulnerabilities, builds software bills of materials, performs dynamic application testing, and provides code intelligence through an interactive knowledge graph and AI chat.
|
||||
Prüfwerk is an AI-powered security compliance platform that scans your Git repositories for vulnerabilities, builds software bills of materials, performs dynamic application testing, and provides code intelligence through an interactive knowledge graph and AI chat.
|
||||
|
||||
## What You Get
|
||||
|
||||
When you connect a repository, Certifai runs a comprehensive scan pipeline that covers:
|
||||
When you connect a repository, Prüfwerk runs a comprehensive scan pipeline that covers:
|
||||
|
||||
- **Static Analysis (SAST)** -- finds code-level vulnerabilities like injection flaws, insecure crypto, and misconfigurations
|
||||
- **Software Bill of Materials (SBOM)** -- inventories every dependency, its version, and its license
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Issues & Tracking
|
||||
|
||||
Certifai 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.
|
||||
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
|
||||
|
||||
@@ -8,7 +8,7 @@ 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 Certifai
|
||||
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.
|
||||
@@ -53,4 +53,4 @@ Issues are deduplicated using the same fingerprint hash that deduplicates findin
|
||||
|
||||
## 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 Certifai and the development workflow in your tracker.
|
||||
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.
|
||||
|
||||
+8
-8
@@ -1,10 +1,10 @@
|
||||
# PLC / SPS Projects (CODESYS)
|
||||
|
||||
Certifai analyzes industrial control logic (IEC 61131-3) for PLC/SPS targets such
|
||||
Prüfwerk analyzes industrial control logic (IEC 61131-3) for PLC/SPS targets such
|
||||
as CODESYS projects. A single PLC/SPS target is treated as a **composite device**:
|
||||
the control application *and* the device it runs on.
|
||||
|
||||
| What you provide | What Certifai does |
|
||||
| What you provide | What Prüfwerk does |
|
||||
| --- | --- |
|
||||
| PLC project (PLCopen XML / ST, or a `.projectarchive`) | **Control-logic SAST** — semantic security rules over ST **and** graphical FBD/LD |
|
||||
| A `.projectarchive` | **Control-app SBOM** — the referenced CODESYS libraries + the runtime version, matched against known CVEs |
|
||||
@@ -28,7 +28,7 @@ Because of this, the device is built along **two independent tracks**, by
|
||||
different people, on different timelines, and shipped separately. It also
|
||||
inherits the **entire Linux / IT attack surface on top of** the OT / control
|
||||
one — which is exactly why a PLC/SPS target is treated as a **composite**:
|
||||
Certifai ingests one artifact per layer and scans each with the right pipeline.
|
||||
Prüfwerk ingests one artifact per layer and scans each with the right pipeline.
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
@@ -44,7 +44,7 @@ flowchart TB
|
||||
A3 --> DEV(["Running soft-PLC device<br/>SoC + Linux + runtime + control app<br/>Modbus · OPC UA · EtherNet/IP · WebVisu"])
|
||||
B3 --> DEV
|
||||
|
||||
subgraph CERT["What Certifai scans — one layer per artifact"]
|
||||
subgraph CERT["What Prüfwerk scans — one layer per artifact"]
|
||||
direction LR
|
||||
S1["Firmware layer<br/>FirmwareStatic · SBOM · CVE"]
|
||||
S2["Control-logic layer<br/>PLC SAST — ST + FBD/LD"]
|
||||
@@ -70,7 +70,7 @@ flowchart TB
|
||||
::: tip Where Yocto fits
|
||||
Yocto is **Track A** — the *build system* for the device platform. It produces
|
||||
the Linux image and bakes in the CODESYS runtime, so it is the **firmware
|
||||
layer**, entirely separate from the control application. Hand it to Certifai as
|
||||
layer**, entirely separate from the control application. Hand it to Prüfwerk as
|
||||
its own **firmware image** artifact (scanned by the firmware pipeline, not the
|
||||
PLC pipeline). The device OS need not be Yocto — Raspbian/Debian/Buildroot, or
|
||||
even an RTOS / bare-metal, are all possible — but Yocto is the common,
|
||||
@@ -79,7 +79,7 @@ product-grade industrial choice.
|
||||
|
||||
## Two ways to deliver the project
|
||||
|
||||
You can either **upload** the project when onboarding, or point Certifai at a
|
||||
You can either **upload** the project when onboarding, or point Prüfwerk at a
|
||||
**git repository** (recommended — every scan is just a `git pull`, no re-upload).
|
||||
|
||||
### Option A — Upload
|
||||
@@ -95,7 +95,7 @@ project** artifact and pick its format:
|
||||
|
||||
### Option B — Git repository (recommended)
|
||||
|
||||
Attach a **Git repository** artifact to the PLC/SPS target. Certifai clones it and
|
||||
Attach a **Git repository** artifact to the PLC/SPS target. Prüfwerk clones it and
|
||||
runs the control-logic scan over the exported source in the repo.
|
||||
|
||||
## Best-case git repository layout
|
||||
@@ -145,7 +145,7 @@ surface real CODESYS advisories as CVE alerts.
|
||||
|
||||
## Dynamic testing — ICS protocol probe
|
||||
|
||||
Beyond the static analysis, Certifai can **probe the running device** over
|
||||
Beyond the static analysis, Prüfwerk can **probe the running device** over
|
||||
industrial protocols. Attach a **Live URL** artifact (the device host / WebVisu
|
||||
URL) to the PLC/SPS target and enable the **ICS Probe** scan.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Adding Repositories
|
||||
|
||||
Repositories are the core resource in Certifai. Each tracked repository is scanned on a schedule, and its results are available across all features -- findings, SBOM, code graph, AI chat, and issue tracking.
|
||||
Repositories are the core resource in Prüfwerk. Each tracked repository is scanned on a schedule, and its results are available across all features -- findings, SBOM, code graph, AI chat, and issue tracking.
|
||||
|
||||
## Adding a Repository
|
||||
|
||||
@@ -20,11 +20,11 @@ The repository appears in the list immediately. It will not be scanned until you
|
||||
|
||||
**Public repositories** can be cloned using an HTTPS URL with no additional setup.
|
||||
|
||||
**Private repositories** require SSH access. When you add a repository with an SSH URL (e.g. `git@github.com:org/repo.git`), Certifai uses an SSH deploy key to authenticate.
|
||||
**Private repositories** require SSH access. When you add a repository with an SSH URL (e.g. `git@github.com:org/repo.git`), Prüfwerk uses an SSH deploy key to authenticate.
|
||||
|
||||
### Getting the SSH Public Key
|
||||
|
||||
To grant Certifai access to a private repository:
|
||||
To grant Prüfwerk access to a private repository:
|
||||
|
||||
1. Go to the **Repositories** page
|
||||
2. The platform's SSH public key is available for copying
|
||||
@@ -34,7 +34,7 @@ To grant Certifai access to a private repository:
|
||||
- **Gitea**: Repository Settings > Deploy Keys > Add Deploy Key
|
||||
|
||||
::: tip
|
||||
Deploy keys are scoped to a single repository and are read-only by default. This is the recommended approach for granting Certifai access to private code.
|
||||
Deploy keys are scoped to a single repository and are read-only by default. This is the recommended approach for granting Prüfwerk access to private code.
|
||||
:::
|
||||
|
||||
## Configuring an Issue Tracker
|
||||
|
||||
+1
-1
@@ -6,7 +6,7 @@ The SBOM (Software Bill of Materials) feature provides a complete inventory of a
|
||||
|
||||
A Software Bill of Materials is a list of every component (library, package, framework) that your software depends on, along with version numbers, licenses, and known vulnerabilities. SBOMs are increasingly required for compliance audits, customer security questionnaires, and supply chain transparency.
|
||||
|
||||
Certifai generates SBOMs automatically during each scan using Syft for dependency extraction and OSV.dev + NVD for vulnerability matching.
|
||||
Prüfwerk generates SBOMs automatically during each scan using Syft for dependency extraction and OSV.dev + NVD for vulnerability matching.
|
||||
|
||||
## Packages Tab
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Running Scans
|
||||
|
||||
Scans are the primary workflow in Certifai. Each scan analyzes a repository for security vulnerabilities, dependency risks, and code structure.
|
||||
Scans are the primary workflow in Prüfwerk. Each scan analyzes a repository for security vulnerabilities, dependency risks, and code structure.
|
||||
|
||||
## What Happens During a Scan
|
||||
|
||||
When a scan is triggered, Certifai runs through these phases in order:
|
||||
When a scan is triggered, Prüfwerk runs through these phases in order:
|
||||
|
||||
1. **Clone** -- pulls the latest code from the Git remote (or clones it for the first time)
|
||||
2. **SAST** -- runs static analysis using Semgrep with rules covering OWASP, GDPR, OAuth, secrets, and general security patterns
|
||||
|
||||
+13
-13
@@ -1,15 +1,15 @@
|
||||
# Webhooks & PR Reviews
|
||||
|
||||
Webhooks let Certifai respond to events in your Git repositories automatically. When configured, pushes to your repository trigger scans, and pull requests receive automated security reviews.
|
||||
Webhooks let Prüfwerk respond to events in your Git repositories automatically. When configured, pushes to your repository trigger scans, and pull requests receive automated security reviews.
|
||||
|
||||
## What Webhooks Enable
|
||||
|
||||
- **Automatic scans on push** -- every time code is pushed to your default branch, a scan is triggered automatically
|
||||
- **PR security reviews** -- when a pull request is opened or updated, Certifai scans the changes and posts a review comment summarizing any security findings in the diff
|
||||
- **PR security reviews** -- when a pull request is opened or updated, Prüfwerk scans the changes and posts a review comment summarizing any security findings in the diff
|
||||
|
||||
## Finding the Webhook URL and Secret
|
||||
|
||||
Each repository in Certifai has its own webhook URL and secret:
|
||||
Each repository in Prüfwerk has its own webhook URL and secret:
|
||||
|
||||
1. Go to **Repositories**
|
||||
2. Click **Edit** on the repository you want to configure
|
||||
@@ -22,8 +22,8 @@ Each repository in Certifai has its own webhook URL and secret:
|
||||
|
||||
1. Go to your repository in Gitea
|
||||
2. Navigate to **Settings > Webhooks > Add Webhook > Gitea**
|
||||
3. Set the **Target URL** to the webhook URL from Certifai
|
||||
4. Set the **Secret** to the webhook secret from Certifai
|
||||
3. Set the **Target URL** to the webhook URL from Prüfwerk
|
||||
4. Set the **Secret** to the webhook secret from Prüfwerk
|
||||
5. Under **Trigger On**, select:
|
||||
- **Push Events** -- for automatic scans on push
|
||||
- **Pull Request Events** -- for PR security reviews
|
||||
@@ -34,9 +34,9 @@ Each repository in Certifai has its own webhook URL and secret:
|
||||
|
||||
1. Go to your repository on GitHub
|
||||
2. Navigate to **Settings > Webhooks > Add webhook**
|
||||
3. Set the **Payload URL** to the webhook URL from Certifai
|
||||
3. Set the **Payload URL** to the webhook URL from Prüfwerk
|
||||
4. Set the **Content type** to `application/json`
|
||||
5. Set the **Secret** to the webhook secret from Certifai
|
||||
5. Set the **Secret** to the webhook secret from Prüfwerk
|
||||
6. Under **Which events would you like to trigger this webhook?**, select **Let me select individual events**, then check:
|
||||
- **Pushes** -- for automatic scans on push
|
||||
- **Pull requests** -- for PR security reviews
|
||||
@@ -46,8 +46,8 @@ Each repository in Certifai has its own webhook URL and secret:
|
||||
|
||||
1. Go to your project in GitLab
|
||||
2. Navigate to **Settings > Webhooks**
|
||||
3. Set the **URL** to the webhook URL from Certifai
|
||||
4. Set the **Secret token** to the webhook secret from Certifai
|
||||
3. Set the **URL** to the webhook URL from Prüfwerk
|
||||
4. Set the **Secret token** to the webhook secret from Prüfwerk
|
||||
5. Under **Trigger**, check:
|
||||
- **Push events** -- for automatic scans on push
|
||||
- **Merge request events** -- for PR security reviews
|
||||
@@ -57,10 +57,10 @@ Each repository in Certifai has its own webhook URL and secret:
|
||||
|
||||
When a pull request (or merge request) is opened or updated, the following happens:
|
||||
|
||||
1. Your Git provider sends a webhook event to Certifai
|
||||
2. Certifai checks out the PR branch and runs a targeted scan on the changed files
|
||||
1. Your Git provider sends a webhook event to Prüfwerk
|
||||
2. Prüfwerk checks out the PR branch and runs a targeted scan on the changed files
|
||||
3. Findings specific to the changes in the PR are identified
|
||||
4. Certifai posts a review comment on the PR summarizing:
|
||||
4. Prüfwerk posts a review comment on the PR summarizing:
|
||||
- Number of new findings introduced by the changes
|
||||
- Severity breakdown
|
||||
- Details for each finding including file, line, and remediation guidance
|
||||
@@ -83,5 +83,5 @@ Here is a summary of which events to enable for each feature:
|
||||
You can enable one or both depending on your workflow.
|
||||
|
||||
::: warning
|
||||
Make sure the webhook secret matches exactly between your Git provider and Certifai. Requests with an invalid signature are rejected.
|
||||
Make sure the webhook secret matches exactly between your Git provider and Prüfwerk. Requests with an invalid signature are rejected.
|
||||
:::
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
layout: home
|
||||
|
||||
hero:
|
||||
name: Certifai
|
||||
name: Prüfwerk
|
||||
text: AI-Powered Security Compliance
|
||||
tagline: Automated SAST, SBOM, DAST, CVE monitoring, and code intelligence for your repositories
|
||||
actions:
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Glossary
|
||||
|
||||
A reference of key terms used throughout Certifai.
|
||||
A reference of key terms used throughout Prüfwerk.
|
||||
|
||||
## Security Terms
|
||||
|
||||
**SAST (Static Application Security Testing)**
|
||||
Analysis of source code to find vulnerabilities without running the application. Certifai uses Semgrep for SAST scanning.
|
||||
Analysis of source code to find vulnerabilities without running the application. Prüfwerk uses Semgrep for SAST scanning.
|
||||
|
||||
**DAST (Dynamic Application Security Testing)**
|
||||
Testing a running application by sending crafted requests and analyzing responses. Finds vulnerabilities that only appear at runtime.
|
||||
@@ -45,26 +45,26 @@ A license that allows broad freedom to use, modify, and distribute software with
|
||||
## Standards and Formats
|
||||
|
||||
**CycloneDX**
|
||||
An OWASP standard for SBOM formats. Certifai supports export in CycloneDX 1.5 JSON format.
|
||||
An OWASP standard for SBOM formats. Prüfwerk supports export in CycloneDX 1.5 JSON format.
|
||||
|
||||
**SPDX (Software Package Data Exchange)**
|
||||
A Linux Foundation standard for communicating software bill of materials information. Certifai supports export in SPDX 2.3 format.
|
||||
A Linux Foundation standard for communicating software bill of materials information. Prüfwerk supports export in SPDX 2.3 format.
|
||||
|
||||
## Tools
|
||||
|
||||
**Semgrep**
|
||||
An open-source static analysis tool that finds bugs and enforces code standards using pattern-matching rules. Used by Certifai for SAST scanning.
|
||||
An open-source static analysis tool that finds bugs and enforces code standards using pattern-matching rules. Used by Prüfwerk for SAST scanning.
|
||||
|
||||
**Syft**
|
||||
An open-source tool for generating SBOMs from container images and filesystems. Used by Certifai to extract dependency information.
|
||||
An open-source tool for generating SBOMs from container images and filesystems. Used by Prüfwerk to extract dependency information.
|
||||
|
||||
**OSV.dev**
|
||||
Google's open distributed vulnerability database, queried by package URL. Certifai uses it (together with NVD) to match SBOM components against known vulnerabilities.
|
||||
Google's open distributed vulnerability database, queried by package URL. Prüfwerk uses it (together with NVD) to match SBOM components against known vulnerabilities.
|
||||
|
||||
## Protocols
|
||||
|
||||
**MCP (Model Context Protocol)**
|
||||
An open standard that allows LLM-powered tools to connect to external data sources and call tools. Certifai exposes security data through MCP so AI assistants can query findings, SBOMs, and DAST results.
|
||||
An open standard that allows LLM-powered tools to connect to external data sources and call tools. Prüfwerk exposes security data through MCP so AI assistants can query findings, SBOMs, and DAST results.
|
||||
|
||||
**PKCE (Proof Key for Code Exchange)**
|
||||
An extension to the OAuth 2.0 authorization code flow that prevents authorization code interception attacks. Used in Certifai's authentication flow.
|
||||
An extension to the OAuth 2.0 authorization code flow that prevents authorization code interception attacks. Used in Prüfwerk's authentication flow.
|
||||
|
||||
@@ -4,9 +4,9 @@ A soft PLC is a **SoC + Linux + a software runtime + an IEC 61131-3 control app*
|
||||
(see [PLC / SPS Projects](/guide/plc)).
|
||||
The **runtime** is what defines the device — it provides the IEC engine, the
|
||||
Modbus / OPC UA / EtherNet/IP servers, and the WebVisu. This page tracks the
|
||||
runtime ecosystems Certifai may encounter.
|
||||
runtime ecosystems Prüfwerk may encounter.
|
||||
|
||||
We do **not** aim to support every runtime up front. Certifai supports the
|
||||
We do **not** aim to support every runtime up front. Prüfwerk supports the
|
||||
**CODESYS family** today; everything else is a **watch-list** — when a customer
|
||||
shows up using one, we add the parser/support for it then. The dynamic OT probe
|
||||
(Modbus / OPC UA / EtherNet/IP) is **vendor-agnostic** and works regardless of
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# Tools & Scanners
|
||||
|
||||
Certifai uses a combination of open-source scanners and AI-powered analysis to provide comprehensive security coverage. This page describes each tool and how it contributes to the scan pipeline.
|
||||
Prüfwerk uses a combination of open-source scanners and AI-powered analysis to provide comprehensive security coverage. This page describes each tool and how it contributes to the scan pipeline.
|
||||
|
||||
## Semgrep -- Static Analysis (SAST)
|
||||
|
||||
[Semgrep](https://semgrep.dev/) is an open-source static analysis tool that finds vulnerabilities by matching patterns in source code. It supports many languages and has an extensive rule library.
|
||||
|
||||
Certifai runs Semgrep with rules covering:
|
||||
Prüfwerk runs Semgrep with rules covering:
|
||||
|
||||
- **OWASP Top 10** -- injection, broken authentication, XSS, insecure deserialization, and more
|
||||
- **General security** -- insecure cryptography, hardcoded credentials, path traversal
|
||||
@@ -26,7 +26,7 @@ Syft output feeds into both the SBOM feature and the vulnerability scanning pipe
|
||||
|
||||
## OSV.dev + NVD -- Vulnerability Matching
|
||||
|
||||
Certifai matches every SBOM component directly against two public vulnerability sources (no separate scanner binary):
|
||||
Prüfwerk matches every SBOM component directly against two public vulnerability sources (no separate scanner binary):
|
||||
|
||||
- [OSV.dev](https://osv.dev/) -- batch queried by package URL (purl) for ecosystem advisories (npm, PyPI, crates.io, Go, Maven, ...)
|
||||
- [NVD](https://nvd.nist.gov/) -- queried per CVE for the CVSS v3.1 base score, and by CPE for CODESYS runtime versions found in PLC projects
|
||||
@@ -63,7 +63,7 @@ Detects hardcoded secrets and credentials in source code:
|
||||
|
||||
## LLM-Powered Code Review
|
||||
|
||||
Beyond rule-based scanning, Certifai uses an LLM to perform architectural and security code review. The AI reviews code patterns that are too nuanced for static rules, such as:
|
||||
Beyond rule-based scanning, Prüfwerk uses an LLM to perform architectural and security code review. The AI reviews code patterns that are too nuanced for static rules, such as:
|
||||
|
||||
- Business logic flaws
|
||||
- Race conditions
|
||||
|
||||
Reference in New Issue
Block a user