Monitoring Bearer Security Scanner with Vigilmon

Bearer is an open-source static application security testing (SAST) tool that scans your codebase for OWASP Top 10 vulnerabilities, PII data exposure, hardcoded secrets, and insecure API calls. Run it as a CI step or as a persistent scanning server with an optional web dashboard — Bearer catches security issues before they reach production.

But "catching issues before production" only works when Bearer is actually running. A stalled CI scan, an unreachable dashboard, or a PostgreSQL connectivity failure can leave your team with a false sense of security: no alerts, but not because there are no vulnerabilities. Vigilmon gives you uptime monitoring, heartbeat checks, and alerting across every layer of your self-hosted Bearer deployment.

What You'll Set Up

• HTTP uptime monitor for the Bearer web dashboard (port 3000)
• Heartbeat monitor for CI/CD scan pipeline health
• PostgreSQL connectivity probe
• Scan performance heartbeat (P95 scan duration alert)
• Vulnerability rule set freshness check

Prerequisites

• Bearer CLI (bearer) installed and optionally running in server mode
• PostgreSQL configured for scan history storage (optional but recommended)
• Bearer web dashboard running on port 3000 (if using server mode)
• CI/CD integration (GitHub Actions, GitLab CI, or Jenkins)
• A free Vigilmon account

Step 1: Monitor the Bearer Web Dashboard

If you're running Bearer in server mode, the web dashboard on port 3000 is the control plane for your security posture: scan history, vulnerability trends, and team reports all live there. An unreachable dashboard means your security team loses visibility — even if scans are still running in CI.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter https://bearer.yourdomain.com (or http://localhost:3000 if not publicly exposed).
4. Set Check interval to 2 minutes.
5. Set Expected HTTP status to 200.
6. Click Save.

If Bearer's dashboard exposes a health endpoint, prefer it:

https://bearer.yourdomain.com/health

Alert on 2 consecutive failures — a missed security dashboard check means your team may not notice a vulnerability spike.

Step 2: Track CI/CD Scan Pipeline Health with a Heartbeat

Bearer most commonly runs as a CI step. A misconfigured job, a runner outage, or a Bearer version incompatibility can silently skip security scans — your pipeline still passes, but Bearer never ran.

Push a Vigilmon heartbeat at the end of each successful Bearer scan:

GitHub Actions

- name: Run Bearer Security Scan
  run: bearer scan .

- name: Notify Vigilmon
  if: success()
  run: curl -s "${{ secrets.VIGILMON_BEARER_HEARTBEAT_URL }}"

GitLab CI

bearer_scan:
  script:
    - bearer scan .
    - curl -s "$VIGILMON_BEARER_HEARTBEAT_URL"
  only:
    - main
    - merge_requests

Configure the heartbeat in Vigilmon:

1. Add Monitor → Heartbeat / Cron.
2. Name: Bearer CI Scan.
3. Expected interval: 24 hours (adjust to your merge cadence — at minimum, main branch should be scanned daily).
4. Copy the heartbeat URL into your CI secret as VIGILMON_BEARER_HEARTBEAT_URL.

If 24 hours pass without a heartbeat, Bearer scans have stopped running. This is your safety net for the most dangerous silent failure mode.

Step 3: Monitor PostgreSQL Connectivity

Bearer stores scan results and vulnerability history in PostgreSQL. A database connectivity failure means scan results aren't persisted — you lose trend data and may not catch regressions in vulnerability counts.

Add a connectivity probe:

#!/bin/bash
# probe-bearer-db.sh
pg_isready -h localhost -p 5432 -U bearer -d bearer_db && \
  curl -s "$VIGILMON_BEARER_DB_HEARTBEAT_URL" > /dev/null

Schedule every 5 minutes:

*/5 * * * * /opt/bearer/probe-bearer-db.sh

Create the Vigilmon heartbeat monitor:

1. Add Monitor → Heartbeat / Cron.
2. Name: Bearer PostgreSQL.
3. Expected interval: 10 minutes.

A 10-minute window gives you two missed probes before alerting — enough buffer for transient connections without hiding a real outage.

Step 4: Monitor Scan Performance

Large monorepos can take several minutes to scan. If scan duration climbs above your acceptable threshold, CI pipelines slow down and developers may start skipping the security gate locally.

Track scan duration with a timed heartbeat. Add timing to your CI step:

START=$(date +%s)
bearer scan .
END=$(date +%s)
DURATION=$((END - START))

# Alert if scan took more than 300 seconds (5 minutes)
if [ $DURATION -lt 300 ]; then
  curl -s "$VIGILMON_SCAN_PERF_HEARTBEAT_URL"
fi

Configure the heartbeat with the same interval as your scan frequency. If the heartbeat stops arriving, either scans are taking too long or they've stopped running entirely.

For a more precise P95 tracking approach, log scan durations to a file and query it in your probe:

echo "$(date +%s) $DURATION" >> /var/log/bearer/scan-durations.log

# Push heartbeat only when last 10 runs are under 5 minutes P95
P95=$(tail -10 /var/log/bearer/scan-durations.log | awk '{print $2}' | sort -n | awk 'NR==10{print}')
[ "${P95:-0}" -lt 300 ] && curl -s "$VIGILMON_SCAN_PERF_HEARTBEAT_URL"

Step 5: Check Vulnerability Rule Set Freshness

Bearer ships with a built-in rule set for detecting vulnerabilities. Stale rules (no update in 30+ days) mean you're missing newly discovered vulnerability patterns. Check the rule set version as part of your monitoring:

#!/bin/bash
# check-bearer-rules.sh
LAST_UPDATE=$(bearer version 2>/dev/null | grep -i "updated" | awk '{print $NF}')
DAYS_OLD=$(( ( $(date +%s) - $(date -d "$LAST_UPDATE" +%s) ) / 86400 ))

if [ "$DAYS_OLD" -lt 30 ]; then
  curl -s "$VIGILMON_RULES_HEARTBEAT_URL" > /dev/null
fi

If Bearer's version output doesn't include update dates, probe a known-fresh rule file's mtime instead:

RULE_FILE="/usr/local/share/bearer/rules/detect_secrets.yml"
DAYS_OLD=$(( ( $(date +%s) - $(stat -c %Y "$RULE_FILE") ) / 86400 ))
[ "$DAYS_OLD" -lt 30 ] && curl -s "$VIGILMON_RULES_HEARTBEAT_URL"

Schedule weekly:

0 9 * * 1 /opt/bearer/check-bearer-rules.sh

Configure a 7-day heartbeat window. Missing this heartbeat means you're overdue for a Bearer update.

Step 6: Monitor the Bearer Scan API (Server Mode)

In server mode, Bearer exposes a REST API for triggering scans and retrieving results. This is the integration point for any tooling that calls Bearer programmatically.

1. Add Monitor → HTTP / HTTPS.
2. URL: https://bearer.yourdomain.com/api/v1/scans (adjust to your API path).
3. Expected status: 200 or 401 (authentication required, but the server is responding).
4. Interval: 2 minutes.

A 401 is a valid "server is up" signal — it means the process is running and responding, even if the request isn't authenticated.

Alerting Configuration

| Monitor | Alert condition | Suggested channel | |---|---|---| | Web dashboard | Down 4+ minutes | Slack #security | | CI scan heartbeat | Missed 24-hour window | PagerDuty / email | | PostgreSQL | Heartbeat missed | Slack #security | | Scan performance | Heartbeat missed | Slack #engineering | | Rule set freshness | Heartbeat missed 7 days | Email | | Scan API | Down 4+ minutes | Slack #security |

The CI scan heartbeat is the most critical: a missed window means your codebase went unscanned. Route this to PagerDuty or email so it doesn't get lost in Slack noise.

Conclusion

Bearer's value is in the scans it runs — not the binary sitting on a CI runner. Vigilmon ensures you know the moment scans stop executing, results stop persisting, or the dashboard goes dark. With a heartbeat per scan, a database probe, and a dashboard uptime check, you have full observability of your Bearer security pipeline and can catch silent failures before they become security blind spots.

Get started at vigilmon.online — the free plan covers all monitors described in this tutorial.