Firewall Management MPI v3.2

Package firewall rules, suppression policies, alerting, and CI/CD integration

Skill and extension policies moved to Firewall Skills.

Firewall Rules 0

Firewall Skills

These are sample pre-built firewall rule policies you can activate and customize.

Block Confirmed Malware

MPI confidence ≥ 75% + active compromise → block

Quarantine New Packages

Packages less than 48 hours old → warn

Block Credential Theft

RS-001 or NS-004 signals → block

Block Install Hook Abuse

CS-002 + package < 7 days → block

Warn High PS-OSS Risk

PS-OSS score ≥ 80 → warn

Create / Edit Rule

Step 1: What are you protecting against?

The AI Advisor on the right will help you build the rule. Select a scenario or describe your threat:

Block Confirmed Malware

Quarantine New Packages

Block Credential Theft

Block Install Hooks

High OSS Risk

Step 2: What should happen?

Block

Reject immediately. Install fails. CI breaks.

◎

Require Approval

Hold for manual sign-off. CI paused.

▲

Warn

Allow but alert. No blocking.

▪

Audit

Allow silently. Record for compliance.

◉

Allow

Explicitly permit, overriding lower rules.

Step 3: Refine conditions

The AI has pre-filled conditions. Adjust as needed:

MPI Confidence ≥ —

MPI Signals

Max Package Age (hours):

Max Maintainer Age (days):

Estimated impact: — packages matched in last 30 days

Step 4: Review & save

Rule Name *

Description (optional)

Slack Channel (optional)

Rule Name * ⓘ

Rule Name

A unique, human-readable name for this firewall rule. This name appears in audit logs, Slack alerts, and the rules table. Use a descriptive name that explains what the rule does.

Example: Block confirmed malware

Action * ⓘ

Action

What the firewall does when a package matches this rule. Block stops the install; Warn allows but alerts; Audit logs only; Require Approval gates on human review; Allow explicitly permits (use to whitelist).

Example: block

Ecosystem ⓘ

Ecosystem

Apply the rule only to packages from the specified ecosystem. Supported values: npm, pypi, cargo, maven, nuget, gem, go, docker, github-actions. Omit (use All) to match any ecosystem.

Example: npm

Package Pattern ⓘ

Package Name Pattern

Apply the rule only to packages whose name matches this pattern. Supports glob wildcards (*) and basic regex. Example: 'react-*' matches all packages starting with 'react-'.

Example: react-*

Pattern Type ⓘ

Pattern Type

How the package pattern string is evaluated: Glob supports * and ? wildcards (e.g. evil-*); Regex is full regular expression syntax; Exact requires a byte-exact name match.

Example: glob

Priority (1=highest) ⓘ

Priority

Rules are evaluated in ascending priority order. Priority 1 is checked first. When two rules match the same package, the lower-numbered rule wins. Use 1-10 for critical allow rules, 50-100 for standard block rules, 500+ for catch-all defaults.

Example: 100

Min MPI Confidence (0.0-1.0) ⓘ

Min MPI Confidence

Only match packages where Phoenix's malware ML confidence meets or exceeds this threshold. 0.75 = high confidence. 0.5 = moderate (more false positives).

Example: 0.75

MPI Signals ⓘ

MPI Signals (any)

Any of these MPI signal IDs triggers the rule (OR logic). Signal IDs come from the signal taxonomy (e.g. CS-001, NS-004). Use multiple signals to create broad coverage without raising the confidence bar.

Example: CS-001, NS-004

Threat Types ⓘ

Threat Type (any)

Triggers if the classified threat type of the package matches any value in this list. Examples: dropper, backdoor, cryptominer, typosquat, infostealer.

Example: dropper, backdoor

Min PS-OSS Risk Level ⓘ

Min PS-OSS Score

Only match packages where the Phoenix PS-OSS open-source risk score is at or above the selected level. Score incorporates dependency depth, maintainer risk, vulnerability history, and activity signals.

Thresholds: Low = 40, Medium = 60, High = 80

Max Package Age (hours) ⓘ

Max Package Age (hours)

Matches packages published within this number of hours. Use to automatically quarantine very new packages before they are vetted. 48 = two-day quarantine window. 168 = one-week window.

Example: 48

MITRE Techniques ⓘ

MITRE Techniques (any)

Match packages whose detected signals map to any of the specified MITRE ATT&CK technique IDs. Use standard notation such as T1059.007 or T1195.001. Useful for policy alignment with threat models.

Example: T1059.007, T1195.001

Slack Channel ⓘ

Slack Channel

Slack channel ID or name to receive notifications when this rule fires. You can use the channel name (#security-alerts) or the Slack channel ID (C0ABC123). Requires global Slack to be connected in Alert Settings.

Example: #security-alerts

Version Constraint (semver) ⓘ

Version Constraint

Apply the rule only to package versions matching this semver constraint. Standard semver syntax: >=1.0.0 <2.0.0, ~1.2.3, ^4.0.0. Omit to match all versions.

Example: >=1.0.0 <2.0.0

Compromise Status ⓘ

Compromise Status

Filter by compromise recency. 'active' = currently flagged. 'recent_30d' = flagged in the last 30 days. 'any' = any historical compromise record.

Example: active

License Categories ⓘ

License Category (any)

Match packages whose license is classified into one of the specified categories. Categories: copyleft, strong-copyleft, weak-copyleft, permissive, public-domain, proprietary. Use to enforce license policy at the gate.

Example: strong-copyleft, copyleft

Max Maintainer Age (days) ⓘ

Max Maintainer Account Age (days)

Matches packages published by an account created within this number of days. New or throwaway accounts are a strong indicator of supply-chain attack staging. 90 = block accounts younger than 3 months.

Example: 90

CI/CD Signals ⓘ

CI/CD Signals (any)

Any of these CI/CD signal IDs triggers the rule (OR logic). CI signals are PR-diff-only signals (CI-001 through CI-006). Use to gate PRs that modify workflows, register runners, or access secrets.

Example: CI-001, CI-003

Email Recipients ⓘ

Email Recipients

One or more email addresses to notify when this rule fires. Separate multiple addresses with commas. Requires SMTP to be configured in your Phoenix Security instance.

Example: security@company.com, soc@company.com

Slack Channel Selection ⓘ

Slack Channel Selection

Notifications use the global Slack integration configured in Alert Settings. Select a channel override only if this rule should notify a different channel than the global default.

Example: Use Global Default Channel

Description ⓘ

Description

Optional free-text description stored alongside the rule. Use to document the threat scenario, rationale, or policy reference (e.g. "Blocks packages flagged by OSSF malicious packages dataset with active compromise status").

Example: Blocks packages with active credential theft signals

Test Result

◈ AI Rule Advisor

Select a threat scenario or describe what you want to protect against:

Generating rule draft…

Name	Pattern	Type	Ecosystem	Action	Priority	Fire Count	Status	Actions
Loading firewall rules...

Suppression Rules 0

Best-Practice Suppression Templates (Not Active by Default)

These templates are recommendations. Activating one creates a disabled draft that you can review before enabling.

Template	Pattern	Reason	Status	Action
Loading suppression templates...

ID	Pattern	Reason	Suppresses	Fire Count	Source	Actions
Loading suppression rules...

Slack Alert Configuration

Use global Phoenix Security alerting configuration

Checking global configuration...

Open Global Alert Settings

Local Slack Webhook URL (Override)

Used only when global configuration is disabled for this firewall workflow.

Local Slack Channel (Override)

Alert Events

HIGH_SUSPECT AUTO_BLOCK JUDGE_OVERRIDE NEW_MALICIOUS

Alert Frequency

Immediate Hourly Daily

Enable Alerts

Total Rules

Total Fires Today

Blocked Packages

Active IOCs

Rules Fired (Last 7 Days)

Ecosystem Breakdown

Latest Malware Sightings

Package	Version	Ecosystem	Threat Type	Tags	Confirmed
Loading sightings...

GitHub Actions

Block malicious packages in your GitHub Actions CI pipeline before they reach production.

name: Phoenix Firewall Check
on: [push, pull_request]
jobs:
  firewall-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Phoenix Firewall Scan
        run: |
          curl -sSf $PHOENIX_API/firewall/scan \
            -H "Authorization: Bearer ${{ secrets.PHOENIX_TOKEN }}" \
            -d @package-lock.json
        env:
          PHOENIX_API: https://your-instance.cvedetails.io/api/v1/malware-intel

GitLab CI

Integrate Phoenix firewall checks into your GitLab CI/CD pipeline stages.

phoenix-firewall:
  stage: test
  image: curlimages/curl:latest
  script:
    - |
      curl -sSf $PHOENIX_API/firewall/scan \
        -H "Authorization: Bearer $PHOENIX_TOKEN" \
        -d @package-lock.json
  variables:
    PHOENIX_API: "https://your-instance.cvedetails.io/api/v1/malware-intel"

Jenkins

Add Phoenix firewall scanning to your Jenkins declarative or scripted pipelines.

pipeline {
  agent any
  stages {
    stage('Phoenix Firewall') {
      steps {
        withCredentials([string(
          credentialsId: 'phoenix-token',
          variable: 'TOKEN')]) {
          sh '''
            curl -sSf $PHOENIX_API/firewall/scan \
              -H "Authorization: Bearer $TOKEN" \
              -d @package-lock.json
          '''
        }
      }
    }
  }
}

Setup Instructions

Generate an API token from your User Dashboard (Pro or Enterprise tier required).
Store the token as a secret in your CI/CD platform (e.g., PHOENIX_TOKEN).
Copy the appropriate template above into your pipeline configuration.
Replace your-instance.cvedetails.io with your Phoenix Security instance URL.
The scan endpoint accepts package-lock.json, yarn.lock, requirements.txt, Gemfile.lock, go.sum, and pom.xml.
The pipeline will fail with exit code 1 if any blocked packages are detected.

Deploy the Phoenix Security Blue Shield firewall to block malicious and vulnerable packages before they reach your machines, CI pipelines, and AI coding agents. Generate a firewall API key below, then copy a ready-to-run install command — the key is injected automatically.

1 Automated configuration — firewall API key

The firewall authenticates to your Phoenix instance with a scoped API key (api_firewall). Generate one here and it will be wired into the install commands and the export PHOENIX_API_KEY snippet below.

Manage keys in User Dashboard

Inline key generation isn't available here (sign in with a Pro or Enterprise account). Generate a key from your User Dashboard and paste it into the commands below (replace $PHOENIX_API_KEY).

export PHOENIX_API_KEY=phx_your_key_here

2 Blue Shield Firewall — proxy & endpoint

Single Go binary with two modes: proxy mode (MITM on :8080 for CI/CD) and endpoint mode (PATH shims for developer workstations). Repository: Security-Phoenix-demo/blue-shield-firewall.

Install (macOS / Linux)

One-line installer — downloads the latest binary, no root required.

curl -sSfL https://raw.githubusercontent.com/Security-Phoenix-demo/blue-shield-firewall/main/scripts/install.sh | bash

Install (Windows / PowerShell)

Run in an elevated or user PowerShell session.

irm https://raw.githubusercontent.com/Security-Phoenix-demo/blue-shield-firewall/main/scripts/install.ps1 | iex

Proxy mode (CI/CD or dev)

Start the proxy and inject HTTPS_PROXY + CA into the current shell, then run installs.

eval $(phoenix-firewall proxy --api-key $PHOENIX_API_KEY --ci)
npm ci
pip install -r requirements.txt

Endpoint mode (workstation)

Install userland PATH shims once, then enroll with your API key.

phoenix-firewall init
phoenix-firewall enroll --api-key $PHOENIX_API_KEY

GitHub Action

Drop the action into a workflow step; store the key as a repo secret.

- uses: Security-Phoenix-demo/firewall-action@v1
  with:
    api-key: ${{ secrets.PHOENIX_API_KEY }}

Pre-built binaries

Platform	Artifact
macOS (Apple Silicon)	`phoenix-firewall_<ver>_darwin_arm64.tar.gz`
macOS (Intel)	`phoenix-firewall_<ver>_darwin_amd64.tar.gz`
Linux x86_64	`phoenix-firewall_<ver>_linux_amd64.tar.gz`
Linux ARM64	`phoenix-firewall_<ver>_linux_arm64.tar.gz`
Windows x86_64	`phoenix-firewall_<ver>_windows_amd64.zip`

Download latest release Install guide & docs

3 Blue Shield Firewall Agents — AI coding agents

NPM packages, shell hooks, and an MCP server that protect AI coding agents (Claude Code, Cursor, Codex, Windsurf, Cline, Aider, Copilot, Antigravity). Repository: Security-Phoenix-demo/blue-shield-agent-firewall.

Quick start

Scaffold config, detect installed agents, and install the Claude Code hook.

export PHOENIX_API_KEY=phx_your_key_here
npx @phoenix-security/cli init
npx @phoenix-security/cli install-hooks claude-code

MCP server

Expose the phoenix_* tools to any MCP-capable agent.

npx -y @phoenix-security/mcp-firewall

Install CLI globally

Install the CLI for repeated use, then scan a lockfile.

npm install -g @phoenix-security/cli
phoenix-firewall scan package-lock.json

Latest release Agent hub docs

Firewall Management MPI v3.2

Firewall Rules 0

Block Confirmed Malware

Quarantine New Packages

Block Credential Theft

Block Install Hook Abuse

Warn High PS-OSS Risk

Create / Edit Rule

Step 1: What are you protecting against?

Step 2: What should happen?

Step 3: Refine conditions

Step 4: Review & save

Test Result

Suppression Rules 0

Best-Practice Suppression Templates (Not Active by Default)

Slack Alert Configuration

Rules Fired (Last 7 Days)

Ecosystem Breakdown

Latest Malware Sightings

GitHub Actions

GitLab CI

Jenkins

Setup Instructions

1 Automated configuration — firewall API key

2 Blue Shield Firewall — proxy & endpoint

Install (macOS / Linux)

Install (Windows / PowerShell)

Proxy mode (CI/CD or dev)

Endpoint mode (workstation)

GitHub Action

Pre-built binaries

3 Blue Shield Firewall Agents — AI coding agents

Quick start

MCP server

Install CLI globally

Browse Signals

Slack Configuration