Dependency Auditor

Dependency Auditor

Skill Type: POWERFUL

Category: Engineering

Domain: Dependency Management & Security

Overview

The Dependency Auditor is a comprehensive toolkit for analyzing, auditing, and managing dependencies across multi-language software projects. This skill provides deep visibility into your project's dependency ecosystem, enabling teams to identify vulnerabilities, ensure license compliance, optimize dependency trees, and plan safe upgrades.

In modern software development, dependencies form complex webs that can introduce significant security, legal, and maintenance risks. A single project might have hundreds of direct and transitive dependencies, each potentially introducing vulnerabilities, license conflicts, or maintenance burden. This skill addresses these challenges through automated analysis and actionable recommendations.

Core Capabilities

1. Vulnerability Scanning & CVE Matching

Comprehensive Security Analysis

• Scans dependencies against built-in vulnerability databases
• Matches Common Vulnerabilities and Exposures (CVE) patterns
• Identifies known security issues across multiple ecosystems
• Analyzes transitive dependency vulnerabilities
• Provides CVSS scores and exploit assessments
• Tracks vulnerability disclosure timelines
• Maps vulnerabilities to dependency paths

Multi-Language Support

• JavaScript/Node.js: package.json, package-lock.json, yarn.lock
• Python: requirements.txt, pyproject.toml, Pipfile.lock, poetry.lock
• Go: go.mod, go.sum
• Rust: Cargo.toml, Cargo.lock
• Ruby: Gemfile, Gemfile.lock
• Java/Maven: pom.xml, gradle.lockfile
• PHP: composer.json, composer.lock
• C#/.NET: packages.config, project.assets.json

2. License Compliance & Legal Risk Assessment

License Classification System

• Permissive Licenses: MIT, Apache 2.0, BSD (2-clause, 3-clause), ISC
• Copyleft (Strong): GPL (v2, v3), AGPL (v3)
• Copyleft (Weak): LGPL (v2.1, v3), MPL (v2.0)
• Proprietary: Commercial, custom, or restrictive licenses
• Dual Licensed: Multi-license scenarios and compatibility
• Unknown/Ambiguous: Missing or unclear licensing

Conflict Detection

• Identifies incompatible license combinations
• Warns about GPL contamination in permissive projects
• Analyzes license inheritance through dependency chains
• Provides compliance recommendations for distribution
• Generates legal risk matrices for decision-making

3. Outdated Dependency Detection

Version Analysis

• Identifies dependencies with available updates
• Categorizes updates by severity (patch, minor, major)
• Detects pinned versions that may be outdated
• Analyzes semantic versioning patterns
• Identifies floating version specifiers
• Tracks release frequencies and maintenance status

Maintenance Status Assessment

• Identifies abandoned or unmaintained packages
• Analyzes commit frequency and contributor activity
• Tracks last release dates and security patch availability
• Identifies packages with known end-of-life dates
• Assesses upstream maintenance quality

4. Dependency Bloat Analysis

Unused Dependency Detection

• Identifies dependencies that aren't actually imported/used
• Analyzes import statements and usage patterns
• Detects redundant dependencies with overlapping functionality
• Identifies oversized packages for simple use cases
• Maps actual vs. declared dependency usage

Redundancy Analysis

• Identifies multiple packages providing similar functionality
• Detects version conflicts in transitive dependencies
• Analyzes bundle size impact of dependencies
• Identifies opportunities for dependency consolidation
• Maps dependency overlap and duplication

5. Upgrade Path Planning & Breaking Change Risk

Semantic Versioning Analysis

• Analyzes semver patterns to predict breaking changes
• Identifies safe upgrade paths (patch/minor versions)
• Flags major version updates requiring attention
• Tracks breaking changes across dependency updates
• Provides rollback strategies for failed upgrades

Risk Assessment Matrix

• Low Risk: Patch updates, security fixes
• Medium Risk: Minor updates with new features
• High Risk: Major version updates, API changes
• Critical Risk: Dependencies with known breaking changes

Upgrade Prioritization

• Security patches: Highest priority
• Bug fixes: High priority
• Feature updates: Medium priority
• Major rewrites: Planned priority
• Deprecated features: Immediate attention

6. Supply Chain Security

Dependency Provenance

• Verifies package signatures and checksums
• Analyzes package download sources and mirrors
• Identifies suspicious or compromised packages
• Tracks package ownership changes and maintainer shifts
• Detects typosquatting and malicious packages

Transitive Risk Analysis

• Maps complete dependency trees
• Identifies high-risk transitive dependencies
• Analyzes dependency depth and complexity
• Tracks influence of indirect dependencies
• Provides supply chain risk scoring

7. Lockfile Analysis & Deterministic Builds

Lockfile Validation

• Ensures lockfiles are up-to-date with manifests
• Validates integrity hashes and version consistency
• Identifies drift between environments
• Analyzes lockfile conflicts and resolution strategies
• Ensures deterministic, reproducible builds

Environment Consistency

• Compares dependencies across environments (dev/staging/prod)
• Identifies version mismatches between team members
• Validates CI/CD environment consistency
• Tracks dependency resolution differences

Technical Architecture

Scanner Engine (dep_scanner.py)

• Multi-format parser supporting 8+ package ecosystems
• Built-in vulnerability database with 500+ CVE patterns
• Transitive dependency resolution from lockfiles
• JSON and human-readable output formats
• Configurable scanning depth and exclusion patterns

License Analyzer (license_checker.py)

• License detection from package metadata and files
• Compatibility matrix with 20+ license types
• Conflict detection engine with remediation suggestions
• Risk scoring based on distribution and usage context
• Export capabilities for legal review

Upgrade Planner (upgrade_planner.py)

• Semantic version analysis with breaking change prediction
• Dependency ordering based on risk and interdependence
• Migration checklists with testing recommendations
• Rollback procedures for failed upgrades
• Timeline estimation for upgrade cycles

Use Cases & Applications

Security Teams

• Vulnerability Management: Continuous scanning for security issues
• Incident Response: Rapid assessment of vulnerable dependencies
• Supply Chain Monitoring: Tracking third-party security posture
• Compliance Reporting: Automated security compliance documentation

Legal & Compliance Teams

• License Auditing: Comprehensive license compliance verification
• Risk Assessment: Legal risk analysis for software distribution
• Due Diligence: Dependency licensing for M&A activities
• Policy Enforcement: Automated license policy compliance

Development Teams

• Dependency Hygiene: Regular cleanup of unused dependencies
• Upgrade Planning: Strategic dependency update scheduling
• Performance Optimization: Bundle size optimization through dep analysis
• Technical Debt: Identifying and prioritizing dependency technical debt

DevOps & Platform Teams

• Build Optimization: Faster builds through dependency optimization
• Security Automation: Automated vulnerability scanning in CI/CD
• Environment Consistency: Ensuring consistent dependencies across environments
• Release Management: Dependency-aware release planning

Integration Patterns

CI/CD Pipeline Integration

# Security gate in CI
python dep_scanner.py /project --format json --fail-on-high
python license_checker.py /project --policy strict --format json

Scheduled Audits

# Weekly dependency audit
./audit_dependencies.sh > weekly_report.html
python upgrade_planner.py deps.json --timeline 30days

Development Workflow

# Pre-commit dependency check
python dep_scanner.py . --quick-scan
python license_checker.py . --warn-conflicts

Advanced Features

Custom Vulnerability Databases

• Support for internal/proprietary vulnerability feeds
• Custom CVE pattern definitions
• Organization-specific risk scoring
• Integration with enterprise security tools

Policy-Based Scanning

• Configurable license policies by project type
• Custom risk thresholds and escalation rules
• Automated policy enforcement and notifications
• Exception management for approved violations

Reporting & Dashboards

• Executive summaries for management
• Technical reports for development teams
• Trend analysis and dependency health metrics
• Integration with project management tools

Multi-Project Analysis

• Portfolio-level dependency analysis
• Shared dependency impact analysis
• Organization-wide license compliance
• Cross-project vulnerability propagation

Best Practices

Scanning Frequency

• Security Scans: Daily or on every commit
• License Audits: Weekly or monthly
• Upgrade Planning: Monthly or quarterly
• Full Dependency Audit: Quarterly

Risk Management

1. Prioritize Security: Address high/critical CVEs immediately 2. License First: Ensure compliance before functionality 3. Gradual Updates: Incremental dependency updates 4. Test Thoroughly: Comprehensive testing after updates 5. Monitor Continuously: Automated monitoring and alerting

Team Workflows

1. Security Champions: Designate dependency security owners 2. Review Process: Mandatory review for new dependencies 3. Update Cycles: Regular, scheduled dependency updates 4. Documentation: Maintain dependency rationale and decisions 5. Training: Regular team education on dependency security

Metrics & KPIs

Security Metrics

• Mean Time to Patch (MTTP) for vulnerabilities
• Number of high/critical vulnerabilities
• Percentage of dependencies with known vulnerabilities
• Security debt accumulation rate

Compliance Metrics

• License compliance percentage
• Number of license conflicts
• Time to resolve compliance issues
• Policy violation frequency

Maintenance Metrics

• Percentage of up-to-date dependencies
• Average dependency age
• Number of abandoned dependencies
• Upgrade success rate

Efficiency Metrics

• Bundle size reduction percentage
• Unused dependency elimination rate
• Build time improvement
• Developer productivity impact

Troubleshooting Guide

Common Issues

1. False Positives: Tuning vulnerability detection sensitivity 2. License Ambiguity: Resolving unclear or multiple licenses 3. Breaking Changes: Managing major version upgrades 4. Performance Impact: Optimizing scanning for large codebases

Resolution Strategies

• Whitelist false positives with documentation
• Contact maintainers for license clarification
• Implement feature flags for risky upgrades
• Use incremental scanning for large projects

Future Enhancements

Planned Features

• Machine learning for vulnerability prediction
• Automated dependency update pull requests
• Integration with container image scanning
• Real-time dependency monitoring dashboards
• Natural language policy definition

Ecosystem Expansion

• Additional language support (Swift, Kotlin, Dart)
• Container and infrastructure dependencies
• Development tool and build system dependencies
• Cloud service and SaaS dependency tracking

---

Quick Start

# Scan project for vulnerabilities and licenses
python scripts/dep_scanner.py /path/to/project

# Check license compliance
python scripts/license_checker.py /path/to/project --policy strict

# Plan dependency upgrades
python scripts/upgrade_planner.py deps.json --risk-threshold medium

For detailed usage instructions, see README.md.

---

This skill provides comprehensive dependency management capabilities essential for maintaining secure, compliant, and efficient software projects. Regular use helps teams stay ahead of security threats, maintain legal compliance, and optimize their dependency ecosystems.

Troubleshooting

Success Criteria

• Zero critical CVEs in production dependencies -- all HIGH/CRITICAL vulnerabilities resolved or documented with approved exceptions before release.
• License compliance at 100% -- every direct dependency has a known, classified license; zero UNKNOWN licenses ship to production.
• No unresolved license conflicts -- all detected conflicts have documented resolutions or approved waivers.
• Outdated dependency ratio below 15% -- at least 85% of direct dependencies are within one minor version of the latest release.
• Mean Time to Patch (MTTP) under 7 days -- high-severity vulnerability patches applied within one week of disclosure.
• Upgrade plan coverage above 90% -- phased upgrade plans exist for all dependencies with available major or security updates.
• Scan integration in CI/CD -- dep_scanner.py --fail-on-high runs on every pull request with zero unacknowledged failures.

Scope & Limitations

This skill covers:

• Parsing dependency manifests and lockfiles for JavaScript/Node.js, Python, Go, Rust, Ruby, Java, PHP, and C#/.NET ecosystems.
• Matching dependencies against a built-in vulnerability database of common CVE patterns with severity scoring.
• Classifying licenses into risk tiers (permissive, weak copyleft, strong copyleft, proprietary, unknown) and detecting conflicts.
• Generating prioritized, phased upgrade plans with breaking-change analysis, rollback procedures, and time estimates.

This skill does NOT cover:

• Real-time querying of live vulnerability databases (NVD, OSV, GitHub Advisory); the built-in database is a representative subset. For continuous monitoring, see skill-security-auditor.
• Container image or OS-level package scanning. For infrastructure-layer auditing, see ci-cd-pipeline-builder or observability-designer.
• Automated pull request creation for dependency updates (e.g., Dependabot/Renovate-style). The skill produces plans and reports, not automated code changes.
• Runtime dependency analysis or dynamic import tracing; detection relies on static manifest and lockfile parsing only.

Integration Points

Tool Reference

dep_scanner.py

Purpose: Scans a project directory for dependency manifest and lockfile files across 8+ ecosystems, extracts direct and transitive dependencies, matches them against a built-in vulnerability database, and produces a security report.

Usage:

python scripts/dep_scanner.py <project_path> [options]

Parameters:

Example:

python scripts/dep_scanner.py /app --format json --output scan.json --fail-on-high

Output Formats:

• text -- Human-readable report with summary, vulnerable dependency list, and numbered recommendations.
• json -- Machine-readable JSON with dependencies, scan_summary, vulnerabilities_found, severity counts, and recommendations arrays.

---

license_checker.py

Purpose: Analyzes dependency licenses from package metadata and LICENSE files, classifies them by risk tier, detects license compatibility conflicts against the project license, and calculates a compliance score.

Usage:

python scripts/license_checker.py <project_path> [options]

Parameters:

Example:

python scripts/license_checker.py /app --policy strict --format json --output licenses.json

Output Formats:

• text -- Compliance report with project license, per-dependency license classification, conflict details, compliance score, and recommendations.
• json -- Structured JSON with project_license, dependencies (each with license_declared, license_detected, confidence), conflicts, compliance_score, and risk_assessment.

---

upgrade_planner.py

Purpose: Reads a dependency inventory JSON file, evaluates semantic versioning gaps against a simulated registry, assesses breaking-change risk, and produces a phased upgrade plan with prioritized recommendations, migration checklists, and rollback procedures.

Usage:

python scripts/upgrade_planner.py <inventory_file> [options]

Parameters:

Example:

python scripts/upgrade_planner.py scan.json --timeline 30 --risk-threshold medium --format json

Output Formats:

• text -- Phased upgrade plan with per-dependency risk assessment, breaking-change notes, estimated time, rollback complexity, and prioritized recommendations.
• json -- Structured JSON with available_upgrades (each with update_type, risk_level, security_updates, breaking_changes, priority_score), upgrade_statistics, risk_assessment, and upgrade_plans arrays.

Dependency Auditor

A comprehensive toolkit for analyzing, auditing, and managing dependencies across multi-language software projects. This skill provides vulnerability scanning, license compliance checking, and upgrade path planning with zero external dependencies.

Overview

The Dependency Auditor skill consists of three main Python scripts that work together to provide complete dependency management capabilities:

• `dep_scanner.py`: Vulnerability scanning and dependency analysis
• `license_checker.py`: License compliance and conflict detection
• `upgrade_planner.py`: Upgrade path planning and risk assessment

Features

🔍 Vulnerability Scanning

• Multi-language dependency parsing (JavaScript, Python, Go, Rust, Ruby, Java)
• Built-in vulnerability database with common CVE patterns
• CVSS scoring and risk assessment
• JSON and human-readable output formats
• CI/CD integration support

⚖️ License Compliance

• Comprehensive license classification and compatibility analysis
• Automatic conflict detection between project and dependency licenses
• Risk assessment for commercial usage and distribution
• Compliance scoring and reporting

📈 Upgrade Planning

• Semantic versioning analysis with breaking change prediction
• Risk-based upgrade prioritization
• Phased migration plans with rollback procedures
• Security-focused upgrade recommendations

Installation

No external dependencies required! All scripts use only Python standard library.

# Clone or download the dependency-auditor skill
cd engineering/dependency-auditor/scripts

# Make scripts executable
chmod +x dep_scanner.py license_checker.py upgrade_planner.py

Quick Start

1. Scan for Vulnerabilities

# Basic vulnerability scan
python dep_scanner.py /path/to/your/project

# JSON output for automation
python dep_scanner.py /path/to/your/project --format json --output scan_results.json

# Fail CI/CD on high-severity vulnerabilities
python dep_scanner.py /path/to/your/project --fail-on-high

2. Check License Compliance

# Basic license compliance check
python license_checker.py /path/to/your/project

# Strict policy enforcement
python license_checker.py /path/to/your/project --policy strict

# Use existing dependency inventory
python license_checker.py /path/to/project --inventory scan_results.json --format json

3. Plan Dependency Upgrades

# Generate upgrade plan from dependency inventory
python upgrade_planner.py scan_results.json

# Custom timeline and risk filtering
python upgrade_planner.py scan_results.json --timeline 60 --risk-threshold medium

# Security updates only
python upgrade_planner.py scan_results.json --security-only --format json

Detailed Usage

Dependency Scanner (dep_scanner.py)

The dependency scanner parses project files to extract dependencies and check them against a built-in vulnerability database.

Supported File Formats

• JavaScript/Node.js: package.json, package-lock.json, yarn.lock
• Python: requirements.txt, pyproject.toml, Pipfile.lock, poetry.lock
• Go: go.mod, go.sum
• Rust: Cargo.toml, Cargo.lock
• Ruby: Gemfile, Gemfile.lock

Command Line Options

python dep_scanner.py [PROJECT_PATH] [OPTIONS]

Required Arguments:
  PROJECT_PATH          Path to the project directory to scan

Optional Arguments:
  --format {text,json}  Output format (default: text)
  --output FILE         Output file path (default: stdout)
  --fail-on-high        Exit with error code if high-severity vulnerabilities found
  --quick-scan          Perform quick scan (skip transitive dependencies)

Examples:
  python dep_scanner.py /app
  python dep_scanner.py . --format json --output results.json
  python dep_scanner.py /project --fail-on-high --quick-scan

Output Format

Text Output:

============================================================
DEPENDENCY SECURITY SCAN REPORT
============================================================
Scan Date: 2024-02-16T15:30:00.000Z
Project: /example/sample-web-app

SUMMARY:
  Total Dependencies: 23
  Unique Dependencies: 19
  Ecosystems: npm
  Vulnerabilities Found: 1
    High Severity: 1
    Medium Severity: 0
    Low Severity: 0

VULNERABLE DEPENDENCIES:
------------------------------
Package: lodash v4.17.20 (npm)
  • CVE-2021-23337: Prototype pollution in lodash
    Severity: HIGH (CVSS: 7.2)
    Fixed in: 4.17.21

RECOMMENDATIONS:
--------------------
1. URGENT: Address 1 high-severity vulnerabilities immediately
2. Update lodash from 4.17.20 to 4.17.21 to fix CVE-2021-23337

JSON Output:

{
  "timestamp": "2024-02-16T15:30:00.000Z",
  "project_path": "/example/sample-web-app",
  "dependencies": [
    {
      "name": "lodash",
      "version": "4.17.20",
      "ecosystem": "npm",
      "direct": true,
      "vulnerabilities": [
        {
          "id": "CVE-2021-23337",
          "summary": "Prototype pollution in lodash",
          "severity": "HIGH",
          "cvss_score": 7.2
        }
      ]
    }
  ],
  "recommendations": [
    "Update lodash from 4.17.20 to 4.17.21 to fix CVE-2021-23337"
  ]
}

License Checker (license_checker.py)

The license checker analyzes dependency licenses for compliance and detects potential conflicts.

Command Line Options

python license_checker.py [PROJECT_PATH] [OPTIONS]

Required Arguments:
  PROJECT_PATH          Path to the project directory to analyze

Optional Arguments:
  --inventory FILE      Path to dependency inventory JSON file
  --format {text,json}  Output format (default: text)  
  --output FILE         Output file path (default: stdout)
  --policy {permissive,strict}  License policy strictness (default: permissive)
  --warn-conflicts      Show warnings for potential conflicts

Examples:
  python license_checker.py /app
  python license_checker.py . --format json --output compliance.json
  python license_checker.py /app --inventory deps.json --policy strict

License Classifications

The tool classifies licenses into risk categories:

• Permissive (Low Risk): MIT, Apache-2.0, BSD, ISC
• Weak Copyleft (Medium Risk): LGPL, MPL
• Strong Copyleft (High Risk): GPL, AGPL
• Proprietary (High Risk): Commercial licenses
• Unknown (Critical Risk): Unidentified licenses

Compatibility Matrix

The tool includes a comprehensive compatibility matrix that checks:

• Project license vs. dependency licenses
• GPL contamination detection
• Commercial usage restrictions
• Distribution requirements

Upgrade Planner (upgrade_planner.py)

The upgrade planner analyzes dependency inventories and creates prioritized upgrade plans.

Command Line Options

python upgrade_planner.py [INVENTORY_FILE] [OPTIONS]

Required Arguments:
  INVENTORY_FILE        Path to dependency inventory JSON file

Optional Arguments:
  --timeline DAYS       Timeline for upgrade plan in days (default: 90)
  --format {text,json}  Output format (default: text)
  --output FILE         Output file path (default: stdout)
  --risk-threshold {safe,low,medium,high,critical}  Maximum risk level (default: high)
  --security-only       Only plan upgrades with security fixes

Examples:
  python upgrade_planner.py deps.json
  python upgrade_planner.py inventory.json --timeline 60 --format json
  python upgrade_planner.py deps.json --security-only --risk-threshold medium

Risk Assessment

Upgrades are classified by risk level:

• Safe: Patch updates with no breaking changes
• Low: Minor updates with backward compatibility
• Medium: Updates with potential API changes
• High: Major version updates with breaking changes
• Critical: Updates affecting core functionality

Phased Planning

The tool creates three-phase upgrade plans:

1. Phase 1 (30% of timeline): Security fixes and safe updates 2. Phase 2 (40% of timeline): Regular maintenance updates 3. Phase 3 (30% of timeline): Major updates requiring careful planning

Integration Examples

CI/CD Pipeline Integration

GitHub Actions Example

name: Dependency Audit
on: [push, pull_request, schedule]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.9'
      
      - name: Run Vulnerability Scan
        run: |
          python scripts/dep_scanner.py . --format json --output scan.json
          python scripts/dep_scanner.py . --fail-on-high
      
      - name: Check License Compliance
        run: |
          python scripts/license_checker.py . --inventory scan.json --policy strict
      
      - name: Generate Upgrade Plan
        run: |
          python scripts/upgrade_planner.py scan.json --output upgrade-plan.txt
      
      - name: Upload Reports
        uses: actions/upload-artifact@v3
        with:
          name: dependency-reports
          path: |
            scan.json
            upgrade-plan.txt

Jenkins Pipeline Example

pipeline {
    agent any
    
    stages {
        stage('Dependency Audit') {
            steps {
                script {
                    // Vulnerability scan
                    sh 'python scripts/dep_scanner.py . --format json --output scan.json'
                    
                    // License compliance
                    sh 'python scripts/license_checker.py . --inventory scan.json --format json --output compliance.json'
                    
                    // Upgrade planning
                    sh 'python scripts/upgrade_planner.py scan.json --format json --output upgrades.json'
                }
                
                // Archive reports
                archiveArtifacts artifacts: '*.json', fingerprint: true
                
                // Fail build on high-severity vulnerabilities
                sh 'python scripts/dep_scanner.py . --fail-on-high'
            }
        }
    }
    
    post {
        always {
            // Publish reports
            publishHTML([
                allowMissing: false,
                alwaysLinkToLastBuild: true,
                keepAll: true,
                reportDir: '.',
                reportFiles: '*.json',
                reportName: 'Dependency Audit Report'
            ])
        }
    }
}

Automated Dependency Updates

Weekly Security Updates Script

#!/bin/bash
# weekly-security-updates.sh

set -e

echo "Running weekly security dependency updates..."

# Scan for vulnerabilities
python scripts/dep_scanner.py . --format json --output current-scan.json

# Generate security-only upgrade plan
python scripts/upgrade_planner.py current-scan.json --security-only --output security-upgrades.txt

# Check if security updates are available
if grep -q "URGENT" security-upgrades.txt; then
    echo "Security updates found! Creating automated PR..."
    
    # Create branch
    git checkout -b "automated-security-updates-$(date +%Y%m%d)"
    
    # Apply updates (example for npm)
    npm audit fix --only=prod
    
    # Commit and push
    git add .
    git commit -m "chore: automated security dependency updates"
    git push origin HEAD
    
    # Create PR (using GitHub CLI)
    gh pr create \
        --title "Automated Security Updates" \
        --body-file security-upgrades.txt \
        --label "security,dependencies,automated"
else
    echo "No critical security updates found."
fi

Sample Files

The assets/ directory contains sample dependency files for testing:

• sample_package.json: Node.js project with various dependencies
• sample_requirements.txt: Python project dependencies
• sample_go.mod: Go module dependencies

The expected_outputs/ directory contains example reports showing the expected format and content.

Advanced Usage

Custom Vulnerability Database

You can extend the built-in vulnerability database by modifying the _load_vulnerability_database() method in dep_scanner.py:

def _load_vulnerability_database(self):
    """Load vulnerability database from multiple sources."""
    db = self._load_builtin_database()
    
    # Load custom vulnerabilities
    custom_db_path = os.environ.get('CUSTOM_VULN_DB')
    if custom_db_path and os.path.exists(custom_db_path):
        with open(custom_db_path, 'r') as f:
            custom_vulns = json.load(f)
            db.update(custom_vulns)
    
    return db

Custom License Policies

Create custom license policies by modifying the license database:

# Add custom license
custom_license = LicenseInfo(
    name='Custom Internal License',
    spdx_id='CUSTOM-1.0',
    license_type=LicenseType.PROPRIETARY,
    risk_level=RiskLevel.HIGH,
    description='Internal company license',
    restrictions=['Internal use only'],
    obligations=['Attribution required']
)

Multi-Project Analysis

For analyzing multiple projects, create a wrapper script:

#!/usr/bin/env python3
import os
import json
from pathlib import Path

projects = ['/path/to/project1', '/path/to/project2', '/path/to/project3']
results = {}

for project in projects:
    project_name = Path(project).name
    
    # Run vulnerability scan
    scan_result = subprocess.run([
        'python', 'scripts/dep_scanner.py', 
        project, '--format', 'json'
    ], capture_output=True, text=True)
    
    if scan_result.returncode == 0:
        results[project_name] = json.loads(scan_result.stdout)

# Generate consolidated report
with open('consolidated-report.json', 'w') as f:
    json.dump(results, f, indent=2)

Troubleshooting

Common Issues

1. Permission Errors

   chmod +x scripts/*.py

2. Python Version Compatibility

• Requires Python 3.7 or higher
• Uses only standard library modules

3. Large Projects

• Use --quick-scan for faster analysis
• Consider excluding large node_modules directories

4. False Positives

• Review vulnerability matches manually
• Consider version range parsing improvements

Debug Mode

Enable debug logging by setting environment variable:

export DEPENDENCY_AUDIT_DEBUG=1
python scripts/dep_scanner.py /your/project

Contributing

1. Adding New Package Managers: Extend the supported_files dictionary and add corresponding parsers 2. Vulnerability Database: Add new CVE entries to the built-in database 3. License Support: Add new license types to the license database 4. Risk Assessment: Improve risk scoring algorithms

References

• SKILL.md: Comprehensive skill documentation
• references/: Best practices and compatibility guides
• assets/: Sample dependency files for testing
• expected_outputs/: Example reports and outputs

License

This skill is licensed under the MIT License. See the project license file for details.

---

Note: This tool provides automated analysis to assist with dependency management decisions. Always review recommendations and consult with security and legal teams for critical applications.

Dependency Management Best Practices

A comprehensive guide to effective dependency management across the software development lifecycle, covering strategy, governance, security, and operational practices.

Strategic Foundation

Dependency Strategy

Philosophy and Principles

1. Minimize Dependencies: Every dependency is a liability

• Prefer standard library solutions when possible
• Evaluate alternatives before adding new dependencies
• Regularly audit and remove unused dependencies

2. Quality Over Convenience: Choose well-maintained, secure dependencies

• Active maintenance and community
• Strong security track record
• Comprehensive documentation and testing

3. Stability Over Novelty: Prefer proven, stable solutions

• Avoid dependencies with frequent breaking changes
• Consider long-term support and backwards compatibility
• Evaluate dependency maturity and adoption

4. Transparency and Control: Understand what you're depending on

• Review dependency source code when possible
• Understand licensing implications
• Monitor dependency behavior and updates

Decision Framework

Evaluation Criteria

Dependency Evaluation Scorecard:
│
├── Necessity (25 points)
│   ├── Problem complexity (10)
│   ├── Standard library alternatives (8)
│   └── Internal implementation effort (7)
│
├── Quality (30 points)
│   ├── Code quality and architecture (10)
│   ├── Test coverage and reliability (10)
│   └── Documentation completeness (10)
│
├── Maintenance (25 points)
│   ├── Active development and releases (10)
│   ├── Issue response time (8)
│   └── Community size and engagement (7)
│
└── Compatibility (20 points)
    ├── License compatibility (10)
    ├── Version stability (5)
    └── Platform/runtime compatibility (5)

Scoring:
- 80-100: Excellent choice
- 60-79: Good choice with monitoring
- 40-59: Acceptable with caution
- Below 40: Avoid or find alternatives

Governance Framework

Dependency Approval Process

New Dependency Approval

New Dependency Workflow:
│
1. Developer identifies need
   ├── Documents use case and requirements
   ├── Researches available options
   └── Proposes recommendation
   ↓
2. Technical review
   ├── Architecture team evaluates fit
   ├── Security team assesses risks
   └── Legal team reviews licensing
   ↓
3. Management approval
   ├── Low risk: Tech lead approval
   ├── Medium risk: Architecture board
   └── High risk: CTO approval
   ↓
4. Implementation
   ├── Add to approved dependencies list
   ├── Document usage guidelines
   └── Configure monitoring and alerts

Risk Classification

• Low Risk: Well-known libraries, permissive licenses, stable APIs
• Medium Risk: Less common libraries, weak copyleft licenses, evolving APIs
• High Risk: New/experimental libraries, strong copyleft licenses, breaking changes

Dependency Policies

Licensing Policy

licensing_policy:
  allowed_licenses:
    - MIT
    - Apache-2.0
    - BSD-3-Clause
    - BSD-2-Clause
    - ISC
  
  conditional_licenses:
    - LGPL-2.1  # Library linking only
    - LGPL-3.0  # With legal review
    - MPL-2.0   # File-level copyleft acceptable
  
  prohibited_licenses:
    - GPL-2.0   # Strong copyleft
    - GPL-3.0   # Strong copyleft
    - AGPL-3.0  # Network copyleft
    - SSPL      # Server-side public license
    - Custom    # Unknown/proprietary licenses
  
  exceptions:
    process: "Legal and executive approval required"
    documentation: "Risk assessment and mitigation plan"

Security Policy

security_policy:
  vulnerability_response:
    critical: "24 hours"
    high: "1 week"
    medium: "1 month"
    low: "Next release cycle"
  
  scanning_requirements:
    frequency: "Daily automated scans"
    tools: ["Snyk", "OWASP Dependency Check"]
    ci_cd_integration: "Mandatory security gates"
  
  approval_thresholds:
    known_vulnerabilities: "Zero tolerance for high/critical"
    maintenance_status: "Must be actively maintained"
    community_size: "Minimum 10 contributors or enterprise backing"

Operational Practices

Dependency Lifecycle Management

Addition Process

1. Research and Evaluation

   # Example evaluation script
   #!/bin/bash
   PACKAGE=$1
   
   echo "=== Package Analysis: $PACKAGE ==="
   
   # Check package stats
   npm view $PACKAGE
   
   # Security audit
   npm audit $PACKAGE
   
   # License check
   npm view $PACKAGE license
   
   # Dependency tree
   npm ls $PACKAGE
   
   # Recent activity
   npm view $PACKAGE --json | jq '.time'

2. Documentation Requirements

• Purpose: Why this dependency is needed
• Alternatives: Other options considered and why rejected
• Risk Assessment: Security, licensing, maintenance risks
• Usage Guidelines: How to use safely within the project
• Exit Strategy: How to remove/replace if needed

3. Integration Standards

• Pin to specific versions (avoid wildcards)
• Document version constraints and reasoning
• Configure automated update policies
• Add monitoring and alerting

Update Management

Update Strategy

Update Prioritization:
│
├── Security Updates (P0)
│   ├── Critical vulnerabilities: Immediate
│   ├── High vulnerabilities: Within 1 week
│   └── Medium vulnerabilities: Within 1 month
│
├── Maintenance Updates (P1)
│   ├── Bug fixes: Next minor release
│   ├── Performance improvements: Next minor release
│   └── Deprecation warnings: Plan for major release
│
└── Feature Updates (P2)
    ├── Minor versions: Quarterly review
    ├── Major versions: Annual planning cycle
    └── Breaking changes: Dedicated migration projects

Update Process

update_workflow:
  automated:
    patch_updates:
      enabled: true
      auto_merge: true
      conditions:
        - tests_pass: true
        - security_scan_clean: true
        - no_breaking_changes: true
    
    minor_updates:
      enabled: true
      auto_merge: false
      requires: "Manual review and testing"
    
    major_updates:
      enabled: false
      requires: "Full impact assessment and planning"

  testing_requirements:
    unit_tests: "100% pass rate"
    integration_tests: "Full test suite"
    security_tests: "Vulnerability scan clean"
    performance_tests: "No regression"

  rollback_plan:
    automated: "Failed CI/CD triggers automatic rollback"
    manual: "Documented rollback procedure"
    monitoring: "Real-time health checks post-deployment"

Removal Process

1. Deprecation Planning

• Identify deprecated/unused dependencies
• Assess removal impact and effort
• Plan migration timeline and strategy
• Communicate to stakeholders

2. Safe Removal

   # Example removal checklist
   echo "Dependency Removal Checklist:"
   echo "1. [ ] Grep codebase for all imports/usage"
   echo "2. [ ] Check if any other dependencies require it"
   echo "3. [ ] Remove from package files"
   echo "4. [ ] Run full test suite"
   echo "5. [ ] Update documentation"
   echo "6. [ ] Deploy with monitoring"

Version Management

Semantic Versioning Strategy

Version Pinning Policies

version_pinning:
  production_dependencies:
    strategy: "Exact pinning"
    example: "react: 18.2.0"
    rationale: "Predictable builds, security control"
  
  development_dependencies:
    strategy: "Compatible range"
    example: "eslint: ^8.0.0"
    rationale: "Allow bug fixes and improvements"
  
  internal_libraries:
    strategy: "Compatible range"
    example: "^1.2.0"
    rationale: "Internal control, faster iteration"

Update Windows

• Patch Updates (x.y.Z): Allow automatically with testing
• Minor Updates (x.Y.z): Review monthly, apply quarterly
• Major Updates (X.y.z): Annual review cycle, planned migrations

Lockfile Management

Best Practices

1. Always Commit Lockfiles

• package-lock.json (npm)
• yarn.lock (Yarn)
• Pipfile.lock (Python)
• Cargo.lock (Rust)
• go.sum (Go)

2. Lockfile Validation

   # Example CI validation
   - name: Validate lockfile
     run: |
       npm ci --audit
       npm audit --audit-level moderate
       # Verify lockfile is up to date
       npm install --package-lock-only
       git diff --exit-code package-lock.json

3. Regeneration Policy

• Regenerate monthly or after significant updates
• Always regenerate after security updates
• Document regeneration in change logs

Security Management

Vulnerability Management

Continuous Monitoring

monitoring_stack:
  scanning_tools:
    - name: "Snyk"
      scope: "All ecosystems"
      frequency: "Daily"
      integration: "CI/CD + IDE"
    
    - name: "GitHub Dependabot"
      scope: "GitHub repositories"
      frequency: "Real-time"
      integration: "Pull requests"
    
    - name: "OWASP Dependency Check"
      scope: "Java/.NET focus"
      frequency: "Build pipeline"
      integration: "CI/CD gates"

  alerting:
    channels: ["Slack", "Email", "PagerDuty"]
    escalation:
      critical: "Immediate notification"
      high: "Within 1 hour"
      medium: "Daily digest"

Response Procedures

Critical Vulnerability Response

Critical Vulnerability (CVSS 9.0+) Response:
│
0-2 hours: Detection & Assessment
├── Automated scan identifies vulnerability
├── Security team notified immediately
└── Initial impact assessment started
│
2-6 hours: Planning & Communication
├── Detailed impact analysis completed
├── Fix strategy determined
├── Stakeholder communication initiated
└── Emergency change approval obtained
│
6-24 hours: Implementation & Testing
├── Fix implemented in development
├── Security testing performed
├── Limited rollout to staging
└── Production deployment prepared
│
24-48 hours: Deployment & Validation
├── Production deployment executed
├── Monitoring and validation performed
├── Post-deployment testing completed
└── Incident documentation finalized

Supply Chain Security

Source Verification

1. Package Authenticity

• Verify package signatures when available
• Use official package registries
• Check package maintainer reputation
• Validate download checksums

2. Build Reproducibility

• Use deterministic builds where possible
• Pin dependency versions exactly
• Document build environment requirements
• Maintain build artifact checksums

Dependency Provenance

provenance_tracking:
  metadata_collection:
    - package_name: "Library identification"
    - version: "Exact version used"
    - source_url: "Official repository"
    - maintainer: "Package maintainer info"
    - license: "License verification"
    - checksum: "Content verification"
  
  verification_process:
    - signature_check: "GPG signature validation"
    - reputation_check: "Maintainer history review"
    - content_analysis: "Static code analysis"
    - behavior_monitoring: "Runtime behavior analysis"

Multi-Language Considerations

Ecosystem-Specific Practices

JavaScript/Node.js

{
  "npm_practices": {
    "package_json": {
      "engines": "Specify Node.js version requirements",
      "dependencies": "Production dependencies only",
      "devDependencies": "Development tools and testing",
      "optionalDependencies": "Use sparingly, document why"
    },
    "security": {
      "npm_audit": "Run in CI/CD pipeline",
      "package_lock": "Always commit to repository",
      "registry": "Use official npm registry or approved mirrors"
    },
    "performance": {
      "bundle_analysis": "Regular bundle size monitoring",
      "tree_shaking": "Ensure unused code is eliminated",
      "code_splitting": "Lazy load dependencies when possible"
    }
  }
}

Python

python_practices:
  dependency_files:
    requirements.txt: "Pin exact versions for production"
    requirements-dev.txt: "Development dependencies"
    setup.py: "Package distribution metadata"
    pyproject.toml: "Modern Python packaging"
  
  virtual_environments:
    purpose: "Isolate project dependencies"
    tools: ["venv", "virtualenv", "conda", "poetry"]
    best_practice: "One environment per project"
  
  security:
    tools: ["safety", "pip-audit", "bandit"]
    practices: ["Pin versions", "Use private PyPI if needed"]

Java/Maven

<!-- Maven best practices -->
<properties>
  <!-- Define version properties -->
  <spring.version>5.3.21</spring.version>
  <junit.version>5.8.2</junit.version>
</properties>

<dependencyManagement>
  <!-- Centralize version management -->
  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-bom</artifactId>
      <version>${spring.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Cross-Language Integration

API Boundaries

• Define clear service interfaces
• Use standard protocols (HTTP, gRPC)
• Document API contracts
• Version APIs independently

Shared Dependencies

• Minimize shared dependencies across services
• Use containerization for isolation
• Document shared dependency policies
• Monitor for version conflicts

Performance and Optimization

Bundle Size Management

Analysis Tools

# JavaScript bundle analysis
npm install -g webpack-bundle-analyzer
webpack-bundle-analyzer dist/main.js

# Python package size analysis
pip install pip-audit
pip-audit --format json | jq '.dependencies[].package_size'

# General dependency tree analysis
dep-tree analyze --format json --output deps.json

Optimization Strategies

1. Tree Shaking: Remove unused code 2. Code Splitting: Load dependencies on demand 3. Polyfill Optimization: Only include needed polyfills 4. Alternative Packages: Choose smaller alternatives when possible

Build Performance

Dependency Caching

# Example CI/CD caching
cache_strategy:
  node_modules:
    key: "npm-{{ checksum 'package-lock.json' }}"
    paths: ["~/.npm", "node_modules"]
  
  pip_cache:
    key: "pip-{{ checksum 'requirements.txt' }}"
    paths: ["~/.cache/pip"]
  
  maven_cache:
    key: "maven-{{ checksum 'pom.xml' }}"
    paths: ["~/.m2/repository"]

Parallel Installation

• Configure package managers for parallel downloads
• Use local package caches
• Consider dependency proxies for enterprise environments

Monitoring and Metrics

Key Performance Indicators

Security Metrics

security_kpis:
  vulnerability_metrics:
    - mean_time_to_detection: "Average time to identify vulnerabilities"
    - mean_time_to_patch: "Average time to fix vulnerabilities"
    - vulnerability_density: "Vulnerabilities per 1000 dependencies"
    - false_positive_rate: "Percentage of false vulnerability reports"
  
  compliance_metrics:
    - license_compliance_rate: "Percentage of compliant dependencies"
    - policy_violation_rate: "Rate of policy violations"
    - security_gate_success_rate: "CI/CD security gate pass rate"

Operational Metrics

operational_kpis:
  maintenance_metrics:
    - dependency_freshness: "Average age of dependencies"
    - update_frequency: "Rate of dependency updates"
    - technical_debt: "Number of outdated dependencies"
  
  performance_metrics:
    - build_time: "Time to install/build dependencies"
    - bundle_size: "Final application size"
    - dependency_count: "Total number of dependencies"

Dashboard and Reporting

Executive Dashboard

• Overall risk score and trend
• Security compliance status
• Cost of dependency management
• Policy violation summary

Technical Dashboard

• Vulnerability count by severity
• Outdated dependency count
• Build performance metrics
• License compliance details

Automated Reports

• Weekly security summary
• Monthly compliance report
• Quarterly dependency review
• Annual strategy assessment

Team Organization and Training

Roles and Responsibilities

Security Champions

• Monitor security advisories
• Review dependency security scans
• Coordinate vulnerability responses
• Maintain security policies

Platform Engineers

• Maintain dependency management infrastructure
• Configure automated scanning and updates
• Manage package registries and mirrors
• Support development teams

Development Teams

• Follow dependency policies
• Perform regular security updates
• Document dependency decisions
• Participate in security training

Training Programs

Security Training

• Dependency security fundamentals
• Vulnerability assessment and response
• Secure coding practices
• Supply chain attack awareness

Tool Training

• Package manager best practices
• Security scanning tool usage
• CI/CD security integration
• Incident response procedures

Conclusion

Effective dependency management requires a holistic approach combining technical practices, organizational policies, and cultural awareness. Key success factors:

1. Proactive Strategy: Plan dependency management from project inception 2. Clear Governance: Establish and enforce dependency policies 3. Automated Processes: Use tools to scale security and maintenance 4. Continuous Monitoring: Stay informed about dependency risks and updates 5. Team Training: Ensure all team members understand security implications 6. Regular Review: Periodically assess and improve dependency practices

Remember that dependency management is an investment in long-term project health, security, and maintainability. The upfront effort to establish good practices pays dividends in reduced security risks, easier maintenance, and more stable software systems.

License Compatibility Matrix

This document provides a comprehensive reference for understanding license compatibility when combining open source software dependencies in your projects.

Understanding License Types

Permissive Licenses

• MIT License: Very permissive, allows commercial use, modification, and distribution
• Apache 2.0: Permissive with patent grant and trademark restrictions
• BSD 3-Clause: Permissive with non-endorsement clause
• BSD 2-Clause: Simple permissive license
• ISC License: Functionally equivalent to MIT

Weak Copyleft Licenses

• LGPL 2.1/3.0: Library-level copyleft, allows linking but requires modifications to be shared
• MPL 2.0: File-level copyleft, compatible with many licenses

Strong Copyleft Licenses

• GPL 2.0/3.0: Requires entire derivative work to be GPL-licensed
• AGPL 3.0: Extends GPL to network services (SaaS applications)

Compatibility Matrix

Legend:

• ✅ Generally Compatible
• ⚠️ Compatible with conditions/restrictions
• ❌ Incompatible

Detailed Compatibility Rules

MIT Project with Other Licenses

Compatible:

• MIT, Apache-2.0, BSD (all variants), ISC: Full compatibility
• LGPL 2.1/3.0: Can use LGPL libraries via dynamic linking
• MPL 2.0: Can use MPL modules, must keep MPL files under MPL

Incompatible:

• GPL 2.0/3.0: GPL requires entire project to be GPL
• AGPL 3.0: AGPL extends to network services

Apache 2.0 Project with Other Licenses

Compatible:

• MIT, BSD, ISC: Full compatibility
• LGPL 3.0: Compatible (LGPL 3.0 has Apache compatibility clause)
• MPL 2.0: Compatible
• GPL 3.0: Compatible (GPL 3.0 has Apache compatibility clause)

Incompatible:

• LGPL 2.1: License incompatibility
• GPL 2.0: License incompatibility (no Apache clause)

GPL Projects

GPL 2.0 Compatible:

• MIT, BSD, ISC: Can incorporate permissive code
• LGPL 2.1: Compatible
• Other GPL 2.0: Compatible

GPL 2.0 Incompatible:

• Apache 2.0: Different patent clauses
• LGPL 3.0: Version incompatibility
• GPL 3.0: Version incompatibility

GPL 3.0 Compatible:

• All permissive licenses (MIT, Apache, BSD, ISC)
• LGPL 3.0: Version compatibility
• MPL 2.0: Explicit compatibility

Common Compatibility Scenarios

Scenario 1: Permissive Project with GPL Dependency

Problem: MIT-licensed project wants to use GPL library Impact: Entire project must become GPL-licensed Solutions: 1. Find alternative non-GPL library 2. Use dynamic linking (if possible) 3. Change project license to GPL 4. Remove the dependency

Scenario 2: Apache Project with GPL 2.0 Dependency

Problem: Apache 2.0 project with GPL 2.0 dependency Impact: License incompatibility due to patent clauses Solutions: 1. Upgrade to GPL 3.0 if available 2. Find alternative library 3. Use via separate service (API boundary)

Scenario 3: Commercial Product with AGPL Dependency

Problem: Proprietary software using AGPL library Impact: AGPL copyleft extends to network services Solutions: 1. Obtain commercial license 2. Replace with permissive alternative 3. Use via separate service with API boundary 4. Make entire application AGPL

License Combination Rules

Safe Combinations

1. Permissive + Permissive: Always safe 2. Permissive + Weak Copyleft: Usually safe with proper attribution 3. GPL + Compatible Permissive: Safe, result is GPL

Risky Combinations

1. Apache 2.0 + GPL 2.0: Incompatible patent terms 2. Different GPL versions: Version compatibility issues 3. Permissive + Strong Copyleft: Changes project licensing

Forbidden Combinations

1. MIT + GPL (without relicensing) 2. Proprietary + Any Copyleft 3. LGPL 2.1 + Apache 2.0

Distribution Considerations

Binary Distribution

• Must include all required license texts
• Must preserve copyright notices
• Must include source code for copyleft licenses
• Must provide installation instructions for LGPL

Source Distribution

• Must include original license files
• Must preserve copyright headers
• Must document any modifications
• Must provide clear licensing information

SaaS/Network Services

• AGPL extends copyleft to network services
• GPL/LGPL generally don't apply to network services
• Consider service boundaries carefully

Compliance Best Practices

1. License Inventory

• Maintain complete list of all dependencies
• Track license changes in updates
• Document license obligations

2. Compatibility Checking

• Use automated tools for license scanning
• Implement CI/CD license gates
• Regular compliance audits

3. Documentation

• Clear project license declaration
• Complete attribution files
• License change history

4. Legal Review

• Consult legal counsel for complex scenarios
• Review before major releases
• Consider business model implications

Risk Mitigation Strategies

High-Risk Licenses

• AGPL: Avoid in commercial/proprietary projects
• GPL in permissive projects: Plan migration strategy
• Unknown licenses: Investigate immediately

Medium-Risk Scenarios

• Version incompatibilities: Upgrade when possible
• Patent clause conflicts: Seek legal advice
• Multiple copyleft licenses: Verify compatibility

Risk Assessment Framework

1. Identify all dependencies and their licenses 2. Classify by license type and risk level 3. Analyze compatibility with project license 4. Document decisions and rationale 5. Monitor for license changes

Common Misconceptions

❌ Wrong Assumptions

• "MIT allows everything" (still requires attribution)
• "Linking doesn't create derivatives" (depends on license)
• "GPL only affects distribution" (AGPL affects network use)
• "Commercial use is always forbidden" (most FOSS allows it)

✅ Correct Understanding

• Each license has specific requirements
• Combination creates most restrictive terms
• Network use may trigger copyleft (AGPL)
• Commercial licensing options often available

Quick Reference Decision Tree

Is the dependency GPL/AGPL?
├─ YES → Is your project commercial/proprietary?
│   ├─ YES → ❌ Incompatible (find alternative)
│   └─ NO → ✅ Compatible (if same GPL version)
└─ NO → Is it permissive (MIT/Apache/BSD)?
    ├─ YES → ✅ Generally compatible
    └─ NO → Check specific compatibility matrix

Tools and Resources

Automated Tools

• FOSSA: Commercial license scanning
• WhiteSource: Enterprise license management
• ORT: Open source license scanning
• License Finder: Ruby-based license detection

Manual Review Resources

• choosealicense.com: License picker and comparison
• SPDX License List: Standardized license identifiers
• FSF License List: Free Software Foundation compatibility
• OSI Approved Licenses: Open Source Initiative approved licenses

Conclusion

License compatibility is crucial for legal compliance and risk management. When in doubt:

1. Choose permissive licenses for maximum compatibility 2. Avoid strong copyleft in proprietary projects 3. Document all license decisions thoroughly 4. Consult legal experts for complex scenarios 5. Use automated tools for continuous monitoring

Remember: This matrix provides general guidance but legal requirements may vary by jurisdiction and specific use cases. Always consult with legal counsel for important licensing decisions.

Vulnerability Assessment Guide

A comprehensive guide to assessing, prioritizing, and managing security vulnerabilities in software dependencies.

Overview

Dependency vulnerabilities represent one of the most significant attack vectors in modern software systems. This guide provides a structured approach to vulnerability assessment, risk scoring, and remediation planning.

Vulnerability Classification System

Severity Levels (CVSS 3.1)

Critical (9.0 - 10.0)

• Impact: Complete system compromise possible
• Examples: Remote code execution, privilege escalation to admin
• Response Time: Immediate (within 24 hours)
• Business Risk: System shutdown, data breach, regulatory violations

High (7.0 - 8.9)

• Impact: Significant security impact
• Examples: SQL injection, authentication bypass, sensitive data exposure
• Response Time: 7 days maximum
• Business Risk: Data compromise, service disruption

Medium (4.0 - 6.9)

• Impact: Moderate security impact
• Examples: Cross-site scripting (XSS), information disclosure
• Response Time: 30 days
• Business Risk: Limited data exposure, minor service impact

Low (0.1 - 3.9)

• Impact: Limited security impact
• Examples: Denial of service (limited), minor information leakage
• Response Time: Next planned release cycle
• Business Risk: Minimal impact on operations

Vulnerability Types and Patterns

Code Injection Vulnerabilities

SQL Injection

• CWE-89: Improper neutralization of SQL commands
• Common in: Database interaction libraries, ORM frameworks
• Detection: Parameter handling analysis, query construction review
• Mitigation: Parameterized queries, input validation, least privilege DB access

Command Injection

• CWE-78: OS command injection
• Common in: System utilities, file processing libraries
• Detection: System call analysis, user input handling
• Mitigation: Input sanitization, avoid system calls, sandboxing

Code Injection

• CWE-94: Code injection
• Common in: Template engines, dynamic code evaluation
• Detection: eval() usage, dynamic code generation
• Mitigation: Avoid dynamic code execution, input validation, sandboxing

Authentication and Authorization

Authentication Bypass

• CWE-287: Improper authentication
• Common in: Authentication libraries, session management
• Detection: Authentication flow analysis, session handling review
• Mitigation: Multi-factor authentication, secure session management

Privilege Escalation

• CWE-269: Improper privilege management
• Common in: Authorization frameworks, access control libraries
• Detection: Permission checking analysis, role validation
• Mitigation: Principle of least privilege, proper access controls

Data Exposure

Sensitive Data Exposure

• CWE-200: Information exposure
• Common in: Logging libraries, error handling, API responses
• Detection: Log output analysis, error message review
• Mitigation: Data classification, sanitized logging, proper error handling

Cryptographic Failures

• CWE-327: Broken cryptography
• Common in: Cryptographic libraries, hash functions
• Detection: Algorithm analysis, key management review
• Mitigation: Modern cryptographic standards, proper key management

Input Validation Issues

Cross-Site Scripting (XSS)

• CWE-79: Improper neutralization of input
• Common in: Web frameworks, template engines
• Detection: Input handling analysis, output encoding review
• Mitigation: Input validation, output encoding, Content Security Policy

Deserialization Vulnerabilities

• CWE-502: Deserialization of untrusted data
• Common in: Serialization libraries, data processing
• Detection: Deserialization usage analysis
• Mitigation: Avoid untrusted deserialization, input validation

Risk Assessment Framework

CVSS Scoring Components

Base Metrics

1. Attack Vector (AV)

• Network (N): 0.85
• Adjacent (A): 0.62
• Local (L): 0.55
• Physical (P): 0.2

2. Attack Complexity (AC)

• Low (L): 0.77
• High (H): 0.44

3. Privileges Required (PR)

• None (N): 0.85
• Low (L): 0.62/0.68
• High (H): 0.27/0.50

4. User Interaction (UI)

• None (N): 0.85
• Required (R): 0.62

5. Impact Metrics (C/I/A)

• High (H): 0.56
• Low (L): 0.22
• None (N): 0

Temporal Metrics

• Exploit Code Maturity: Proof of concept availability
• Remediation Level: Official fix availability
• Report Confidence: Vulnerability confirmation level

Environmental Metrics

• Confidentiality/Integrity/Availability Requirements: Business impact
• Modified Base Metrics: Environment-specific adjustments

Custom Risk Factors

Business Context

1. Data Sensitivity

• Public data: Low risk multiplier (1.0x)
• Internal data: Medium risk multiplier (1.2x)
• Customer data: High risk multiplier (1.5x)
• Regulated data: Critical risk multiplier (2.0x)

2. System Criticality

• Development: Low impact (1.0x)
• Staging: Medium impact (1.3x)
• Production: High impact (1.8x)
• Core infrastructure: Critical impact (2.5x)

3. Exposure Level

• Internal systems: Base risk
• Partner access: +1 risk level
• Public internet: +2 risk levels
• High-value target: +3 risk levels

Technical Factors

1. Dependency Type

• Direct dependencies: Higher priority
• Transitive dependencies: Lower priority (unless critical path)
• Development dependencies: Lowest priority

2. Usage Pattern

• Core functionality: Highest priority
• Optional features: Medium priority
• Unused code paths: Lowest priority

3. Fix Availability

• Official patch available: Standard timeline
• Workaround available: Extended timeline acceptable
• No fix available: Risk acceptance or replacement needed

Vulnerability Discovery and Monitoring

Automated Scanning

Dependency Scanners

• npm audit: Node.js ecosystem
• pip-audit: Python ecosystem
• bundler-audit: Ruby ecosystem
• OWASP Dependency Check: Multi-language support

Continuous Monitoring

# Example CI/CD integration
name: Security Scan
on: [push, pull_request, schedule]
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run dependency audit
        run: |
          npm audit --audit-level high
          python -m pip_audit
          bundle audit

Commercial Tools

• Snyk: Developer-first security platform
• WhiteSource: Enterprise dependency management
• Veracode: Application security platform
• Checkmarx: Static application security testing

Manual Assessment

Code Review Checklist

1. Input Validation

• [ ] All user inputs validated
• [ ] Proper sanitization applied
• [ ] Length and format restrictions

2. Authentication/Authorization

• [ ] Proper authentication checks
• [ ] Authorization at every access point
• [ ] Session management secure

3. Data Handling

• [ ] Sensitive data protected
• [ ] Encryption properly implemented
• [ ] Secure data transmission

4. Error Handling

• [ ] No sensitive info in error messages
• [ ] Proper logging without data leaks
• [ ] Graceful error handling

Prioritization Framework

Priority Matrix

Prioritization Factors

Technical Factors (40% weight)

1. CVSS Base Score (15%) 2. Exploit Availability (10%) 3. Fix Complexity (8%) 4. Dependency Criticality (7%)

Business Factors (35% weight)

1. Data Impact (15%) 2. System Criticality (10%) 3. Regulatory Requirements (5%) 4. Customer Impact (5%)

Operational Factors (25% weight)

1. Attack Surface (10%) 2. Monitoring Coverage (8%) 3. Incident Response Capability (7%)

Scoring Formula

Priority Score = (Technical Score × 0.4) + (Business Score × 0.35) + (Operational Score × 0.25)

Where each component is scored 1-10:
- 9-10: Critical priority
- 7-8: High priority
- 5-6: Medium priority
- 3-4: Low priority
- 1-2: Informational

Remediation Strategies

Immediate Actions (P0/P1)

Hot Fixes

1. Version Upgrade

• Update to patched version
• Test critical functionality
• Deploy with rollback plan

2. Configuration Changes

• Disable vulnerable features
• Implement additional access controls
• Add monitoring/alerting

3. Workarounds

• Input validation layers
• Network-level protections
• Application-level mitigations

Emergency Response Process

1. Vulnerability Confirmed
   ↓
2. Impact Assessment (2 hours)
   ↓
3. Mitigation Strategy (4 hours)
   ↓
4. Implementation & Testing (12 hours)
   ↓
5. Deployment (2 hours)
   ↓
6. Monitoring & Validation (ongoing)

Planned Remediation (P2/P3)

Standard Update Process

1. Assessment Phase

• Detailed impact analysis
• Testing requirements
• Rollback procedures

2. Planning Phase

• Update scheduling
• Resource allocation
• Communication plan

3. Implementation Phase

• Development environment testing
• Staging environment validation
• Production deployment

4. Validation Phase

• Functionality verification
• Security testing
• Performance monitoring

Alternative Approaches

Dependency Replacement

• When to Consider: No fix available, persistent vulnerabilities
• Process: Impact analysis → Alternative evaluation → Migration planning
• Risks: API changes, feature differences, stability concerns

Accept Risk (Last Resort)

• Criteria: Very low probability, minimal impact, no feasible fix
• Requirements: Executive approval, documented risk acceptance, monitoring
• Conditions: Regular re-assessment, alternative solution tracking

Remediation Tracking

Metrics and KPIs

Vulnerability Metrics

• Mean Time to Detection (MTTD): Average time from publication to discovery
• Mean Time to Patch (MTTP): Average time from discovery to fix deployment
• Vulnerability Density: Vulnerabilities per 1000 dependencies
• Fix Rate: Percentage of vulnerabilities fixed within SLA

Trend Analysis

• Monthly vulnerability counts by severity
• Average age of unpatched vulnerabilities
• Remediation timeline trends
• False positive rates

Reporting Dashboard

Security Dashboard Components:
├── Current Vulnerability Status
│   ├── Critical: 2 (SLA: 24h)
│   ├── High: 5 (SLA: 7d)
│   └── Medium: 12 (SLA: 30d)
├── Trend Analysis
│   ├── New vulnerabilities (last 30 days)
│   ├── Fixed vulnerabilities (last 30 days)
│   └── Average resolution time
└── Risk Assessment
    ├── Overall risk score
    ├── Top vulnerable components
    └── Compliance status

Documentation Requirements

Vulnerability Records

Each vulnerability should be documented with:

• CVE/Advisory ID: Official vulnerability identifier
• Discovery Date: When vulnerability was identified
• CVSS Score: Base and environmental scores
• Affected Systems: Components and versions impacted
• Business Impact: Risk assessment and criticality
• Remediation Plan: Planned fix approach and timeline
• Resolution Date: When fix was implemented and verified

Risk Acceptance Documentation

For accepted risks, document:

• Risk Description: Detailed vulnerability explanation
• Impact Analysis: Potential business and technical impact
• Mitigation Measures: Compensating controls implemented
• Acceptance Rationale: Why risk is being accepted
• Review Schedule: When risk will be reassessed
• Approver: Who authorized the risk acceptance

Integration with Development Workflow

Shift-Left Security

Development Phase

• IDE Integration: Real-time vulnerability detection
• Pre-commit Hooks: Automated security checks
• Code Review: Security-focused review criteria

CI/CD Integration

• Build Stage: Dependency vulnerability scanning
• Test Stage: Security test automation
• Deploy Stage: Final security validation

Production Monitoring

• Runtime Protection: Web application firewalls, runtime security
• Continuous Scanning: Regular dependency updates check
• Incident Response: Automated vulnerability alert handling

Security Gates

security_gates:
  development:
    - dependency_scan: true
    - secret_detection: true
    - code_quality: true
  
  staging:
    - penetration_test: true
    - compliance_check: true
    - performance_test: true
  
  production:
    - final_security_scan: true
    - change_approval: required
    - rollback_plan: verified

Best Practices Summary

Proactive Measures

1. Regular Scanning: Automated daily/weekly scans 2. Update Schedule: Regular dependency maintenance 3. Security Training: Developer security awareness 4. Threat Modeling: Understanding attack vectors

Reactive Measures

1. Incident Response: Well-defined process for critical vulnerabilities 2. Communication Plan: Stakeholder notification procedures 3. Lessons Learned: Post-incident analysis and improvement 4. Recovery Procedures: Rollback and recovery capabilities

Organizational Considerations

1. Responsibility Assignment: Clear ownership of security tasks 2. Resource Allocation: Adequate security budget and staffing 3. Tool Selection: Appropriate security tools for organization size 4. Compliance Requirements: Meeting regulatory and industry standards

Remember: Vulnerability management is an ongoing process requiring continuous attention, regular updates to procedures, and organizational commitment to security best practices.