Vulnerability Scanning API Reference | GeekWala
Loading...
Skip to main content

Integrate GeekWala into Your Workflow

Integrate GeekWala into your CI/CD pipeline with our REST API

API Playground

Test API endpoints directly in your browser. Enter your API token for live requests, or try with mock data to explore the API responses.

API Playground

Get all projects for the authenticated user

GET
/api/v1/projects

Required ability: project:read

No token provided - will show sample response data

curl -X GET "https://geekwala.com/api/v1/projects" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Accept: application/json"

Authentication

Secure API access with token-based authentication.

API Access Requirements

  • Pro & Trial: Full API access
  • Free: Read-only tokens (project:read, scan:read)
  • • API tokens require authenticated Bearer tokens with abilities

Creating API Tokens

1. Navigate to Automation → API Tokens

2. Click "Create New Token"

3. Provide a descriptive name (e.g., "GitHub Actions", "Jenkins Pipeline")

4. Select token abilities (permissions):

project:read

List and view projects

project:write

Create, update, delete projects

scan:read

View scan results

scan:write

Trigger new scans

5. Set expiration: 30 days, 90 days, 1 year, or no expiry

6. Click Create and copy the token immediately (shown only once)

Using API Tokens

Include the token in the Authorization header of all API requests:

curl -H "Authorization: Bearer YOUR_API_TOKEN" \
  https://geekwala.com/api/v1/projects

Security Best Practices

  • • Store tokens as environment variables or CI/CD secrets (never commit to version control)
  • • Use minimal abilities required for each integration
  • • Set expiration dates for tokens used in temporary workflows
  • • Rotate tokens periodically (every 90 days recommended)

API Endpoints

Complete REST API reference for projects and scans.

Base URL

https://geekwala.com/api/v1

Pagination

List endpoints support pagination with query parameters:

Offset Pagination (scan lists)

  • page - Page number (default: 1)
  • per_page - Items per page (default: 50, max: 100)
GET /api/v1/projects/{project}/scans?page=2&per_page=50

Cursor Pagination (scan results)

Scan results use cursor-based pagination for efficient large result sets. Use the cursor value from the links.next URL to fetch subsequent pages.

  • per_page - Items per page (default: 100, max: 500)
  • cursor - Pagination cursor from previous response
GET /api/v1/scans/{id}/results?per_page=100&cursor=eyJpZCI6MTAwfQ

Project Endpoints

MethodEndpointAbilityDescription
GET/projectsproject:readList all projects
GET/projects/{project}project:readGet a specific project
POST/projectsproject:writeCreate a project
PUT/projects/{project}project:writeUpdate a project
DELETE/projects/{project}project:writeDelete a project
POST/projects/{project}/dependenciesproject:writeAdd packages to project

Scan Endpoints

MethodEndpointAbilityDescription
GET/projects/{project}/scansscan:readList scans for a project
GET/scans/{id}scan:readGet a specific scan
GET/scans/{id}/resultsscan:readGet scan results
POST/vulnerability-scan/runscan:writeRun a vulnerability scan
POST/projects/{project}/scansscan:writeTrigger a new scan

Vulnerability Endpoints

MethodEndpointAbilityDescription
GET/vulnerabilities/{vulnerabilityId}scan:readGet full vulnerability details (EPSS, KEV, references)
GET/vulnerabilities/{vulnerabilityId}/headerscan:readGet lightweight header (summary + aliases)
POST/vulnerabilities/headersscan:readBatch fetch headers for multiple vulnerabilities

Rate Limits

API throttling policies for fair usage.

Pro & Trial

Read: 240 req/min

Write: 30 req/min

Free

Read: 120 req/min

Write: 15 req/min

Rate Limit Headers

X-RateLimit-Limit: 120
X-RateLimit-Remaining: 115
X-RateLimit-Reset: 1609459200

Handling 429 Responses

When you exceed the rate limit, the API returns HTTP 429 with a Retry-After header.

async function apiCallWithRetry(url, options, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    const response = await fetch(url, options);
    if (response.status !== 429) return response;

    const retryAfter = response.headers.get('Retry-After');
    await new Promise(resolve =>
      setTimeout(resolve, (retryAfter || (i + 1)) * 1000)
    );
  }
  throw new Error('Max retries exceeded');
}

CI/CD Integration

Scan your dependencies for vulnerabilities in any CI pipeline. Use our official GitHub Action for the best experience, or the REST API for other platforms.

GitHub Actions (Recommended)

The official GeekWala Security Scan action auto-detects your lockfiles, scans for vulnerabilities enriched with EPSS and CISA KEV data, and posts a summary directly to your workflow run.

name: Security Scan
on: [push, pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: GeekWala Security Scan
        uses: Geekwala/security-scan-action@v1
        with:
          api-token: ${{ secrets.GEEKWALA_API_TOKEN }}

That's it. The action auto-detects your dependency file (lockfiles preferred), scans it, and fails the workflow if critical vulnerabilities are found.

Configuring Security Gates

Customize pass/fail criteria with severity thresholds, EPSS scores, and CISA KEV detection:

- name: GeekWala Security Scan
  uses: Geekwala/security-scan-action@v1
  with:
    api-token: ${{ secrets.GEEKWALA_API_TOKEN }}

    # Severity gate: none, low, medium, high, critical
    severity-threshold: high

    # Fail on actively exploited vulnerabilities (CISA KEV)
    fail-on-kev: true

    # Fail if any vulnerability has >30% chance of exploitation
    epss-threshold: 0.3

    # Only fail on vulnerabilities that have a known fix
    only-fixed: true

Monorepo Support

For monorepos or projects with dependency files outside the root, specify the path explicitly with file-path:

- name: GeekWala Security Scan
  uses: Geekwala/security-scan-action@v1
  with:
    api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
    file-path: packages/api/package-lock.json

When file-path is omitted, the action auto-detects dependency files from the repository root (lockfiles preferred over manifests).

GitHub Code Scanning (SARIF)

Generate a SARIF report to surface vulnerabilities in the GitHub Security tab and as PR annotations:

- name: GeekWala Security Scan
  uses: Geekwala/security-scan-action@v1
  with:
    api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
    sarif-file: geekwala-results.sarif
    severity-threshold: none  # Don't fail here; let Code Scanning handle alerts

- name: Upload SARIF to GitHub
  uses: github/codeql-action/upload-sarif@v3
  if: always()
  with:
    sarif_file: geekwala-results.sarif

Suppressing Known Vulnerabilities

Create a .geekwala-ignore.yml file in your repository root to suppress accepted risks:

# .geekwala-ignore.yml
ignore:
  - id: CVE-2021-23337
    reason: "Not exploitable in our usage of lodash"
    expires: 2027-01-01  # Auto-unignore after this date

  - id: GHSA-xxxx-yyyy
    reason: "Accepted risk per security review #42"

Ignored vulnerabilities still appear in scan output (marked as suppressed) but don't count toward failure thresholds.

Advanced Configuration

Fine-tune reliability, output formats, and artifact collection:

- name: GeekWala Security Scan
  uses: Geekwala/security-scan-action@v1
  with:
    api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
    severity-threshold: high

    # Output formats (comma-separated): summary, table, json
    output-format: summary,table,json

    # Save JSON report for CI artifacts
    json-file: scan-results.json

    # Reliability settings for slow CI environments
    retry-attempts: 3       # Retry transient failures (default: 3)
    timeout-seconds: 300    # Scan timeout (default: 300)

- name: Upload scan report
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: security-scan-results
    path: scan-results.json

Using Scan Outputs

The action provides outputs you can use in subsequent workflow steps:

- name: GeekWala Security Scan
  id: scan
  uses: Geekwala/security-scan-action@v1
  with:
    api-token: ${{ secrets.GEEKWALA_API_TOKEN }}
    severity-threshold: none  # Warn only

- name: Comment on PR
  if: steps.scan.outputs.has-vulnerabilities == 'true'
  run: |
    echo "Found ${{ steps.scan.outputs.vulnerable-packages }} vulnerable packages"
    echo "Critical: ${{ steps.scan.outputs.critical-count }}"
    echo "High: ${{ steps.scan.outputs.high-count }}"

Available outputs: scan-status, total-packages, vulnerable-packages, safe-packages, critical-count, high-count, medium-count, low-count, unknown-count, has-vulnerabilities, ignored-count, sarif-file.

Supported Dependency Files

The action auto-detects these files (lockfiles preferred over manifests):

npm: package-lock.json, yarn.lock, pnpm-lock.yaml, package.json
Python: poetry.lock, Pipfile.lock, requirements.txt
PHP: composer.lock, composer.json
Java: pom.xml
Go: go.sum, go.mod
Rust: Cargo.lock, Cargo.toml
Ruby: Gemfile.lock
.NET: packages.lock.json, *.csproj

Quick Scan via API (Any CI System)

For GitLab CI, Jenkins, CircleCI, or any other platform, use the REST API directly:

# Scan package-lock.json and output summary
curl -sf -X POST "https://geekwala.com/api/v1/vulnerability-scan/run" \
  -H "Authorization: Bearer $GEEKWALA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"file_name\": \"package-lock.json\", \"content\": $(cat package-lock.json | jq -Rs .)}" \
  | jq '.data.summary'

# Output: { "total": 150, "affected": 3, "secure": 147, "totalVulnerabilities": 5 }

GitLab CI

Add to your .gitlab-ci.yml. Set GEEKWALA_API_TOKEN in CI/CD Variables:

vulnerability_scan:
  stage: test
  image: alpine:latest
  before_script:
    - apk add --no-cache curl jq
  script:
    - |
      RESPONSE=$(curl -sf -X POST "https://geekwala.com/api/v1/vulnerability-scan/run" \
        -H "Authorization: Bearer $GEEKWALA_API_TOKEN" \
        -H "Content-Type: application/json" \
        -d "{\"file_name\": \"package-lock.json\", \"content\": $(cat package-lock.json | jq -Rs .)}")

      # Parse results
      CRITICAL=$(echo "$RESPONSE" | jq -r '.data.results | map(select(.vulnerabilities[]?.severity == "critical")) | length')
      HIGH=$(echo "$RESPONSE" | jq -r '.data.results | map(select(.vulnerabilities[]?.severity == "high")) | length')

      echo "Critical: $CRITICAL, High: $HIGH"

      # Fail if critical or high found
      if [ "$CRITICAL" -gt 0 ] || [ "$HIGH" -gt 0 ]; then
        echo "Vulnerabilities found! Critical: $CRITICAL, High: $HIGH"
        exit 1
      fi
  # Optional: allow failure for non-blocking scans
  # allow_failure: true

Jenkins Pipeline

Add the token as a Jenkins credential named geekwala-api-token:

pipeline {
  agent any
  environment {
    GEEKWALA_API_TOKEN = credentials('geekwala-api-token')
  }
  stages {
    stage('Vulnerability Scan') {
      steps {
        script {
          def response = sh(
            script: '''
              curl -sf -X POST "https://geekwala.com/api/v1/vulnerability-scan/run" \
                -H "Authorization: Bearer $GEEKWALA_API_TOKEN" \
                -H "Content-Type: application/json" \
                -d "{\"file_name\": \"package-lock.json\", \"content\": $(cat package-lock.json | jq -Rs .)}"
            ''',
            returnStdout: true
          ).trim()

          def json = readJSON text: response
          def critical = json.data.results.count { it.vulnerabilities?.any { v -> v.severity == 'critical' } }
          def high = json.data.results.count { it.vulnerabilities?.any { v -> v.severity == 'high' } }

          echo "Vulnerabilities - Critical: ${critical}, High: ${high}"

          if (critical > 0 || high > 0) {
            error "Found ${critical} critical and ${high} high severity vulnerabilities"
          }
        }
      }
    }
  }
}

Best Practices

  • GitHub? Use the official GitHub Action for the best experience
  • Other CI? Use the vulnerability-scan/run endpoint—it's stateless with no cleanup needed
  • • Store API tokens as secrets (never commit to version control)
  • • Use a dedicated token with only scan:write ability
  • • Start with severity-threshold: none to assess baseline, then enforce
  • • Use project-based scans only when you need historical tracking across builds
  • Examples: See ready-to-use workflows in the examples repository (basic, strict, advanced with SARIF)