Skip to main content
Back to Prompt Library
implementation

Build the application

Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.

Linked challenge: Build a Hardware BOM and Firmware Vulnerability Audit Coordinator

Format
Code-aware
Lines
86
Sections
11
Linked challenge
Build a Hardware BOM and Firmware Vulnerability Audit Coordinator

Prompt source

Original prompt text with formatting preserved for inspection.

86 lines
11 sections
No variables
1 code block
## Build
Audit multi-node accelerator bill-of-materials and out-of-band management firmware against vulnerability databases. Hosted Claude identifies risky firmware revisions and drafts remediation batches.

## User
Infrastructure Security Engineer

## Workflow
1. Ingest standardized hardware inventory files listing host BMC, PCIe switch, and accelerator firmware versions.
2. Cross-examine firmware strings against synthetic security vulnerability advisory notices.
3. Send inventory vulnerability matches to hosted Claude to assess severity, exposure vectors, and operational downtime impact.
4. Export an audit dossier with prioritized maintenance windows and signed operator approval forms.

## Interface
Security audit table with vulnerability severity tags and batch maintenance approval buttons.

## Data
Generate synthetic JSON inventories containing host UUIDs, BMC versions, firmware builds, and mock CVE identifiers.
Starter examples below are synthetic. They are not downloaded records.

## Source
[Anthropic Python SDK](https://raw.githubusercontent.com/anthropics/anthropic-sdk-python/main/README.md)
Employs Anthropic Python SDK to submit hardware BOMs and vulnerability metadata to hosted Claude for structured analysis.

## Tools
crewai, anthropic, pydantic, requests.
CrewAI provides role-based agent coordination between inventory auditing, vulnerability scoring, and maintenance scheduling.
Hosted Claude API for technical vulnerability risk evaluation and batch remediation scheduling.

## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.

## Acceptance
- Flags all inventory records with firmware versions matching known mock security advisories.
- Classifies firmware update urgency into Critical, Moderate, or Low based on network exposure.
- Produces maintenance batch proposals that respect cluster minimum redundancy thresholds.

## Starter Examples
```json
[
  {
    "input": {
      "cluster_env": "training-cluster-1",
      "nodes": [
        {
          "node_id": "node-101",
          "component": "BMC",
          "fw_version": "v1.2.0",
          "vulnerability_id": "MOCK-CVE-2025-101",
          "public_facing": false
        },
        {
          "node_id": "node-102",
          "component": "BMC",
          "fw_version": "v1.4.2",
          "vulnerability_id": null,
          "public_facing": false
        }
      ]
    },
    "expected_output": {
      "vulnerable_count": 1,
      "affected_nodes": [
        "node-101"
      ],
      "priority_tier": "MODERATE",
      "scheduled_maintenance_window": "NEXT_PLANNED_DRAIN"
    }
  },
  {
    "input": {
      "cluster_env": "serving-edge-2",
      "nodes": [
        {
          "node_id": "edge-01",
          "component": "BMC",
          "fw_version": "v1.1.0",
          "vulnerability_id": "MOCK-CVE-2025-999",
          "public_facing": true
        }
      ]
    },
    "expected_output": {
      "vulnerable_count": 1,
      "affected_nodes": [
        "edge-01"
      ],
      "priority_tier": "CRITICAL",
      "scheduled_maintenance_window": "IMMEDIATE_ISOLATION"
    }
  }
]
```

## Safety
Read-only compliance analysis. Does not apply firmware patches or reboot compute nodes.
Use mock external writes. Require human review before any real deployment.

Adaptation plan

Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.

Keep stable

Hold the task contract and output shape stable so generated implementations remain comparable.

Tune next

Update libraries, interfaces, and environment assumptions to match the stack you actually run.

Verify after

Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.