ark-vulnerability-fixer

name	ark-vulnerability-fixer
description	CVE research and security patch workflow for Ark. Provides CVE API integration, mitigation strategies, and security-focused PR templates. Works with research, analysis, and setup skills for comprehensive vulnerability fixing.

Ark Vulnerability Fixer

Provides CVE-specific research tools and security patch workflows for fixing vulnerabilities in Ark.

When to use this skill

Use this skill when:

• User mentions a specific CVE number (e.g., "Fix CVE-2025-55183 in Ark")
• User reports a security vulnerability that needs patching
• You need CVE database information
• You need security-focused PR templates

Note: This skill is typically used by the ark-security-patcher agent as part of a complete workflow:

1. CVE research (this skill + research skill)
2. Codebase analysis (this skill + analysis skill)
3. Mitigation planning (this skill)
4. Repository cloning and fix implementation
5. Testing (optionally with setup skill)
6. PR creation (this skill)

This skill complements the research, analysis, and setup skills for a complete end-to-end vulnerability fixing workflow.

CVE Research

CVE API Integration

Fetch official CVE data from the CIRCL CVE database:

# Fetch CVE details
curl -s "https://cve.circl.lu/api/cve/CVE-2025-55183" | python3 -m json.tool

The API provides:

• Official CVE description
• CVSS scores and severity ratings
• References to security advisories
• Affected products and version ranges
• CWE categorization
• Available patches and fixes

CVE Research Checklist

For each CVE, gather:

• Official CVE description and CVSS score
• Vendor security advisory
• GitHub security advisory (if applicable)
• Patch or fix documentation
• Affected version range
• Recommended version or workaround

Tip: Use the research skill for web searches to find vendor advisories and GitHub security alerts.

Dependency Analysis

Identifying Vulnerable Dependencies

Once you have CVE details, search Ark's dependencies:

cd /tmp/ark-analysis  # Use analysis skill to clone first

# Go dependencies
grep "package-name" go.mod go.sum
go list -m all | grep "package-name"

# Node.js dependencies
find . -name "package.json" -exec grep -l "package-name" {} \;
npm list package-name  # If in a node project

# Python dependencies
find . -name "requirements.txt" -o -name "pyproject.toml" | xargs grep "package-name"

# Docker base images
find . -name "Dockerfile" | xargs grep "FROM"

Assessing Impact

Consider Ark's specific context:

• Deployment model: Kubernetes operator in cluster
• Network exposure: Services typically internal to cluster
• Trust boundary: Often in trusted environments
• Attack vectors: What's realistic given Ark's architecture?

Tip: Use the analysis skill to understand Ark's architecture and service boundaries.

Mitigation Strategy

Presenting Options to User

CRITICAL: Always present mitigation options and wait for user approval before making changes.

Use this template to present findings:

## Security Vulnerability Analysis

### Vulnerability Details
- **CVE**: CVE-YYYY-NNNNN (or "Generic: [description]")
- **Severity**: [Critical/High/Medium/Low] (CVSS: [score])
- **Component**: [Library/package/framework]
- **Description**: [Clear explanation]

### Impact on Ark
- **Affected Services**: [List services/components]
- **Current Version**: [Version in use]
- **Vulnerable Versions**: [Range]
- **Attack Vector**: [How exploitable]
- **Risk Assessment**: [Realistic risk for Ark deployments]

### Mitigation Options

#### Option 1: [Recommended approach] (RECOMMENDED)
- **Action**: Update [component] from v[X] to v[Y]
- **Changes Required**: [Files to modify]
- **Testing Strategy**: [How to verify]
- **Impact**: [Breaking changes, if any]
- **Pros**: [Benefits]
- **Cons**: [Downsides]

#### Option 2: [Alternative approach]
- **Action**: [Alternative fix]
- **Changes Required**: [What changes]
- **Testing Strategy**: [How to verify]
- **Impact**: [Breaking changes, if any]
- **Pros**: [Benefits]
 : [Downsides]


Based on [evidence sources], I recommend  because:
 [Primary reason]
 [Secondary reason]


Would you like to proceed with this mitigation?


 []()
 []()

STOP AND WAIT for user approval before implementing.

Repository Setup for Fixes

Cloning for Development

After user approves the mitigation, clone Ark for making changes:

# Clone the repository
git clone [e-mail]:mckinsey/agents-at-scale-ark.git
cd agents-at-scale-ark

# Create a security fix branch
git checkout -b security/fix-cve-YYYY-NNNNN

# Verify branch
git branch --show-current

For forks:

git clone [e-mail]:<username>/agents-at-scale-ark.git
cd agents-at-scale-ark
git remote add upstream [e-mail]:mckinsey/agents-at-scale-ark.git
git fetch upstream
git checkout -b security/fix-cve-YYYY-NNNNN upstream/main

Implementation

Applying the Fix

Once user approves and repository is cloned, apply changes:

cd agents-at-scale-ark

# For Go dependencies
go get package@v1.2.3
go mod tidy

# For Node.js dependencies
npm install package@1.2.3
npm audit fix

# For Python dependencies
# Edit requirements.txt or pyproject.toml
pip install -r requirements.txt

# For Docker base images
# Edit Dockerfile FROM statements

Verification

Basic Testing

cd agents-at-scale-ark

# Run tests
make test

# Build to check for breaking changes
make build

# Search for remaining vulnerable patterns
grep -r "vulnerable-pattern" .

Integration Testing with Setup Skill (Optional)

For changes that affect Ark runtime behavior, use the setup skill to test in a live cluster:

When to use setup skill for testing:

• Go operator changes (controllers, webhooks, CRDs)
• Service updates (ark-api, executor services)
• Changes that affect Kubernetes interactions
• Breaking changes that need verification

Setup skill workflow:

1. Creates a Kind cluster
2. Builds ark-cli from your security fix branch
3. Installs Ark with your changes
4. Verifies all pods are running
5. Allows you to test the fix in action

Skip integration testing if:

• Only updating documentation or CLI
• Changes are in isolated utility functions
• Dependencies don't affect runtime behavior

Security-Focused PR Templates

Commit Message Template

Ensure you're in the cloned repository:

cd agents-at-scale-ark
git add .

git commit -m "$(cat <<'EOF'
fix: CVE-YYYY-NNNNN in [component]

## Vulnerability Details
- CVE: CVE-YYYY-NNNNN
- Severity: [Critical/High/Medium/Low]
- CVSS Score: [X.X]
- Component: [package/library]

## Impact on Ark
[How this affects Ark services and realistic risk level]

## Changes
- Updated [component] from v[X] to v[Y]
- [Any code changes]

## Testing
- [Tests run and results]

## References
- CVE: https://cve.circl.lu/cve/CVE-YYYY-NNNNN
- Advisory: [URL]

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <[e-mail]>
EOF
)"

Push to Remote

# Push the security fix branch
git push origin security/fix-cve-YYYY-NNNNN

Pull Request Template

Create the PR with detailed security information:

gh pr create --title "fix: CVE-YYYY-NNNNN in [component]" --body "$(cat <<'EOF'
## Summary
Addresses security vulnerability CVE-YYYY-NNNNN in [component].

## Vulnerability Details

| Field | Value |
|-------|-------|
| **CVE** | CVE-YYYY-NNNNN |
| **Severity** | [Critical/High/Medium/Low] |
| **CVSS Score** | [X.X] |
| **Component** | [package] |
| **Current Version** | [old] |
| **Patched Version** | [new] |

### Description
[What the vulnerability is and how it could be exploited]

## Impact on Ark

### Affected Components
- [Service 1]: [Impact]
- [Service 2]: [Impact]

### Risk Assessment
**Risk Level**: [Level]

[Realistic assessment of actual risk to Ark deployments]

## Changes Made
- Updated `[component]` from `v[X]` to `v[Y]`
- [Other changes]

## Testing
- ✅ Unit tests pass
- ✅ Integration tests pass
- ✅ Manual verification completed

## References
- **CVE**: https://cve.circl.lu/cve/CVE-YYYY-NNNNN
- **Advisory**: [URL]
- **Patch Notes**: [URL]

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"

Important Notes

CVE API Usage

The CIRCL CVE API:

• Endpoint: https://cve.circl.lu/api/cve/{CVE-ID}
• Returns JSON with CVSS scores, references, affected versions
• No authentication required
• Fallback: Use web search if API is unreachable

Ark Security Context

When assessing risk:

• Architecture: Kubernetes operator managing AI workloads
• Components: Go operator, Python services, Node.js CLI
• Deployment: Typically cluster-internal, trusted environments
• Focus areas: CRD controllers, API services, executor services

Skill Composition

This skill provides CVE-specific tools. It works best when combined with:

• research skill - For web searches, vendor advisories, evidence gathering
• analysis skill - For cloning Ark repo (read-only) and examining codebase structure
• setup skill - For integration testing in a live Ark cluster
• architecture skill - For understanding service boundaries and impact

Complete workflow example:

1. Research CVE (this skill + research skill)
2. Analyze impact (this skill + analysis skill)
3. Clone for development (this skill)
4. Implement fix (this skill)
5. Test integration (this skill + setup skill, if needed)
6. Create PR (this skill)

User Approval is Mandatory

Never implement changes without explicit user approval. This ensures:

• User understands security implications
• Approach aligns with security policies
• Testing strategy is appropriate
• Breaking changes are acknowledged

Common Vulnerability Types

Go Dependencies

• Check: go.mod, go.sum
• Update: go get package@version && go mod tidy
• Scan: go list -m all

Node.js Dependencies

• Check: package.json, package-lock.json
• Update: npm install package@version
• Scan: npm audit
• Transitive deps: A vulnerable package may appear at multiple versions across nested node_modules/. Check ALL lockfiles:

  find . -name "package-lock.json" -exec grep -l "<package>" {} \;
  jq -r '.packages | to_entries[] | select(.key | contains("<package>")) | "\(.key)\t\(.value.version)"' <lockfile>
  

• npm overrides: Use "overrides" in package.json to force a patched version. But overrides are global — they affect ALL consumers of that package. If two consumers need incompatible major versions (e.g., express 4.x needs path-to-regexp ~0.1.x while router needs ^8.x), an override will break one of them.
• Version conflict resolution: When a transitive dep has incompatible version requirements, consider upgrading the parent package instead. Example: upgrading express 4.x to 5.x unified path-to-regexp to a single 8.x version, resolving the conflict without overrides.

Python Dependencies

• Check: requirements.txt, pyproject.toml
• Update: Edit requirements files
• Scan: pip-audit (if available)

Docker Base Images

• Check: Dockerfile FROM statements
• Update: Change base image version
• Scan: docker scan or vulnerability databases