OWASP DevGuard

DevGuard - Develop Secure Software - Backend

Manage your CVEs seamlessly, Integrate your Vulnerability Scanners, Documentation made easy, Compliance to security Frameworks

Report Bug · Request Feature · Sponsors

Get in touch with the developers directly via Matrix-Chat
Or visit the Documentation

Mission

DevGuard is built by developers, for developers, aiming to simplify the complex world of vulnerability management. Our goal is to integrate security seamlessly into the software development lifecycle, ensuring that security practices are accessible and efficient for everyone, regardless of their security expertise.

Demo

We are using DevGuard to scan and manage the risks of DevGuard itself—essentially eating our own dogfood. The project can be found here:

DEMO

We believe VEX information should be shared via a link due to its dynamic nature, as what is risk-free today may be affected by a CVE tomorrow. We’ve integrated the DevGuard risk scoring into the metrics, with detailed documentation on its calculation to follow soon. SBOM and VEX data are always up to date at these links:

The problem we solve

Identifying and managing software vulnerabilities is an increasingly critical challenge. Developers often face security issues without the proper training or tools that fit into their everyday workflows. DevGuard is a developer-centered software designed to provide simple, modern solutions for vulnerability detection and management, compliant with common security frameworks.

In 2023 alone, cyberattacks caused approximately 206 billion euros in damage only in Germany. Many of these attacks exploited software vulnerabilities. With agile and DevOps methodologies becoming standard, the need for integrating security into the development process has never been greater. We aim to fill this gap with DevGuard, offering a seamless integration of vulnerability management into development workflows.

DevGuard Features

DevGuard comes with a lot of features to make safe Software Development as easy as possible for you. Here are some impressions of feature you will experience while using DevGuard:

Auto-Setup

We developed an auto setup functionality to speed up the DevGuard integration process.

Enhanced Risk Calculation

When it comes to your actual vulnerability risk, the CVSS score is not enough. To help you prioritise based on the actual risk to your project, we enhance the CVSS score with information about exploitability and calculate the risk score based on your confidentiality, integrity and availability assessment. This ensures that the most important things come first!

Dependency overview

Security through obscurity may have worked in the past, but we want to develop software using modern methods! The obscurity shouldn’t affect you either. That’s why we developed DevGuard: to give you full transparency over your dependencies and highlight any vulnerabilities. This is also visible in a fancy dependency graph.

Contributing

We welcome contributions! Please read our contribution guide if you would like to report a bug, ask a question, write issues, or help us with coding. All help is appreciated!

(back to top)

Code of Conduct

Help us keep DevGuard open and inclusive. Please read and follow our Code of Conduct.

(back to top)

Built With

DevGuard is divided into two projects: A frontend (DevGuard Web) and a backend (DevGuard Backend).

Backend (this project):

Frontend:

• Please refer to: DevGuard-Web on Github

(back to top)

Database Migrations

DevGuard uses golang-migrate for database schema management. All migrations are embedded in the binary and run automatically on startup.

How Database Migrations Work

1. Automatic Migration: By default, migrations run automatically when the application starts
2. Environment Control: Set DISABLE_AUTOMIGRATE=true to disable automatic migrations
3. Embedded Migrations: Migration files are embedded in the binary for easy deployment
4. Idempotent: Migrations can be run multiple times safely

Creating New Migrations

1. Install the Migration Tool

The project includes golang-migrate as a tool dependency. Install it using:

go get -tool github.com/golang-migrate/migrate/v4/cmd/migrate

2. Create a New Migration

# Create a new migration file pair (.up.sql and .down.sql)
go tool migrate create -ext sql -dir internal/database/migrations your_migration_name

# Example: Adding a new table
go tool migrate create -ext sql -dir internal/database/migrations add_user_preferences_table

This creates two files:

• internal/database/migrations/YYYYMMDDHHMMSS_your_migration_name.up.sql - Forward migration
• internal/database/migrations/YYYYMMDDHHMMSS_your_migration_name.down.sql - Rollback migration

3. Write Your Migration

Example: Adding a new table

20250801120000_add_user_preferences_table.up.sql:

-- Create user preferences table
CREATE TABLE IF NOT EXISTS user_preferences (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id TEXT NOT NULL,
    theme TEXT DEFAULT 'light',
    notifications_enabled BOOLEAN DEFAULT true,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- Add index for faster lookups
CREATE INDEX IF NOT EXISTS idx_user_preferences_user_id ON user_preferences(user_id);

20250801120000_add_user_preferences_table.down.sql:

-- Remove the user preferences table
DROP TABLE IF EXISTS user_preferences CASCADE;

Example: Adding a column

20250801130000_add_email_to_users.up.sql:

-- Add email column to existing users table
ALTER TABLE users ADD COLUMN IF NOT EXISTS email TEXT;

-- Add index for email lookups
CREATE INDEX IF NOT EXISTS idx_users_email ON users(email);

20250801130000_add_email_to_users.down.sql:

-- Remove email column from users table
ALTER TABLE users DROP COLUMN IF EXISTS email CASCADE;

Example: Adding foreign key constraints

20250801140000_add_user_organization_fk.up.sql:

-- Add foreign key constraint
ALTER TABLE users 
ADD CONSTRAINT IF NOT EXISTS fk_users_organization 
FOREIGN KEY (organization_id) REFERENCES organizations(id) ON DELETE CASCADE;

20250801140000_add_user_organization_fk.down.sql:

-- Remove foreign key constraint
ALTER TABLE users DROP CONSTRAINT IF EXISTS fk_users_organization;

4. Best Practices

• Always use IF NOT EXISTS/IF EXISTS: Makes migrations idempotent
• Include rollback logic: Always write the down migration
• Test migrations: Test both up and down migrations on a copy of production data
• Small incremental changes: Keep migrations focused and atomic
• Use transactions implicitly: PostgreSQL wraps DDL in transactions automatically
• Descriptive names: Use clear, descriptive migration names

5. Manual Migration Commands

# Check migration status
go tool migrate -database "postgres://user:pass@localhost:5432/devguard?sslmode=disable" -path internal/database/migrations version

# Run migrations manually
go tool migrate -database "postgres://user:pass@localhost:5432/devguard?sslmode=disable" -path internal/database/migrations up

# Rollback one migration
go tool migrate -database "postgres://user:pass@localhost:5432/devguard?sslmode=disable" -path internal/database/migrations down 1

# Rollback to specific version
go tool migrate -database "postgres://user:pass@localhost:5432/devguard?sslmode=disable" -path internal/database/migrations goto 20250801120000

(back to top)

License

Distributed under the AGPL-3.0-or-later License. See LICENSE.txt for more information.

(back to top)

Sponsors and Supporters 🚀

We are proud to be supported and working together with the following organizations:

(back to top)

DEVGUARD-SCANNER

Build the scanner

docker build . -f Dockerfile.scanner -t devguard-scanner  

Use the scanner for sca

docker run -v "$(PWD):/app" scanner devguard-scanner sca \
  --assetName="<ASSET NAME>" \
  --apiUrl="http://host.docker.internal:8080" \
  --token="<TOKEN>" \
  --path="/app"

Using the scanner during development

go run ./cmd/devguard-scanner/main.go sca \
  --assetName="<ASSET NAME>" \
  --apiUrl="http://localhost:8080" \
  --token="<TOKEN>"

Scan a container

Build a image.tar from a dockerfile using kaniko

docker run --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=/workspace/Dockerfile --context=/workspace --tarPath=/workspace/image.tar --no-push

Scan the .tar

docker run -v "$(PWD):/app" scanner devguard-scanner container-scanning \
  --assetName="<ASSET NAME>" \
  --apiUrl="http://host.docker.internal:8080" \
  --token="<TOKEN>" \
  --path="/app/image.tar"

Understanding the OWASP DevSecOps Pipeline

DevGuard aims to accompany developers in implementing the OWASP-DevSecOps pipeline in the best way possible, without requiring extensive cybersecurity knowledge. We plan provide a wrapper CLI to a curated list of scanners for different stages and seamless integration with the management backend, ensuring that security is integrated smoothly into the development workflow.

The OWASP DevSecOps pipeline integrates security practices into the DevOps process, ensuring that security is an integral part of the software development lifecycle. The pipeline includes the following key stages and practices:

Secret Scanning (Coming Soon)

• Detects and manages sensitive information such as API keys and passwords that may be accidentally committed to the codebase.
• Helps prevent security breaches by identifying secrets early in the development process.

Software Composition Analysis (SCA)

• Utilizes Software Bill of Materials (SBOMs) to conduct thorough software composition analysis.
• Helps in identifying and managing dependencies and their associated vulnerabilities.
• Prioritizes CVEs using various threat intelligence sources such as EPSS and ExploitDB.
• Focuses on the real risk posed by vulnerabilities, converting “—fail-on-critical” to “—fail-on-real-risk-critical”.
• Syncs with the National Vulnerability Database (NVD) to ensure up-to-date information on vulnerabilities.

Crowdsourced Vulnerability Management

• Supports a crowdsourced approach to vulnerability management.
• If a dependency (A) has another dependency (B) with a CVE, users can consult A to determine the relevance of B’s CVE to their project.
• Allows marking vulnerabilities as false positives, sharing this information across the user community for the same A -> B relationship.

Static Application Security Testing (SAST) (Coming Soon)

• Analyzes source code to identify security vulnerabilities early in the development process.
• Provides developers with actionable insights to fix vulnerabilities before they become critical issues.

Infrastructure as Code (IaC) Scanning

• Ensures that infrastructure definitions and configurations adhere to security best practices.
• Detects misconfigurations and vulnerabilities in IaC templates early in the development cycle.

Container Scanning (Coming Soon)

• Scans container images for vulnerabilities, ensuring that the containerized applications are secure.
• Helps maintain the security of containerized environments by identifying and mitigating risks in container images.

Dynamic Application Security Testing (DAST)

• Tests running applications to identify vulnerabilities that may not be visible in the source code.
• Simulates real-world attacks to uncover potential security weaknesses in live environments.

(back to top)

Joint vulnerability management - the strength of exchange

Based on emerging standards such as the Vulnerability Exploitability eXchange (VEX) and our goal of increasing overall software security through the dissemination of DevGuard, we want to make expert information available from the source.

Vulnerability Exploitability eXchange (VEX)

“The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other parties to assert the status of specific vulnerabilities in a particular product.” (CISA)

VEX is an advanced form of security advisory that provides several key advantages over conventional methods:

1. Machine Readability
2. Enhanced SBOM Integration
3. Automation Support

For instance, consider an open-source project, “XY-Example,” which detects a vulnerability through a dependency. Upon closer inspection, the developers determine that the specific conditions required to exploit this vulnerability are not present in their software. This expert assessment can be recorded and disseminated through VEX, making it accessible and usable for all users of the “XY-Example” software. This exchange of vulnerability information drastically reduces the effort required for vulnerability management, as users can rely on expert evaluations to determine their exposure to potential threats.

Crowdsourced

If the VEX is not available and in its addition, we can also use the knowledge of the crowd. If enough users confirm that a vulnerability in a software is not relevant, we can make this information available to others as a preset. In this way, we expand the foundation for joint vulnerability management and make it even easier.