Your Security Posture
Defines Your Business
Resilience

What is SAST?

Static Application Security Testing analyzes your source code without executing it to find vulnerabilities early in the development lifecycle. Security Factor 365's SAST engine uses AI-enhanced pattern matching and data-flow analysis to detect issues with minimal false positives.

Detection Capabilities

Supported Languages

C#, Java, Python, JavaScript, TypeScript, PHP, Go, Rust, Kotlin, Swift, Ruby, C/C++, Scala, JSX/TSX, Vue, Razor

Key Differentiators

• Best Fix Location — Identifies the root cause point where a single fix resolves multiple findings
• AI-Generated Remediation — Production-ready code fixes with confidence scoring
• ASPM Correlation — Cross-references with SCA, DAST, and IaC findings
• Incremental Scanning — Only scans changed files for fast CI/CD feedback

How Our SAST Engine Works

Unlike simple regex-based scanners, Security Factor 365's SAST engine combines three layers of analysis:

1. Pattern Matching — 30+ hand-tuned detection rules mapped to CWE identifiers and OWASP categories. Each rule includes severity, vulnerability type, and remediation guidance.
2. Data-Flow Analysis — Traces user input from source (HTTP request, form data) to sink (SQL query, command execution, HTML output) to detect injection vulnerabilities that span multiple files.
3. AI Enhancement — Our AI Remediation Agent analyzes each finding in context, generates specific code fixes, and assigns a confidence score so your team knows which fixes to trust immediately.

Example: SQL Injection Detection

var query = "SELECT * FROM Users WHERE Id = " + userId;
var cmd = new SqlCommand(query, connection);

var query = "SELECT * FROM Users WHERE Id = @Id";
var cmd = new SqlCommand(query, connection);
cmd.Parameters.AddWithValue("@Id", userId);

OWASP Top 10 Coverage

What is SCA?

Software Composition Analysis identifies security vulnerabilities, malicious code, and license risks in open-source and third-party dependencies. Our engine scans package manifests, detects transitive dependencies, and cross-references the CVE/NVD databases.

Package Ecosystems

Key Capabilities

• Malicious Package Detection — Database of known malicious packages across all ecosystems
• Exploitable Path Analysis — Determines if vulnerable code is actually reachable
• License Compliance — Flags GPL, AGPL, and other copyleft licenses
• SBOM Generation — Automated SPDX and CycloneDX output
• SLSA Framework — Supply chain integrity tracking (Levels 0-3)

Why Secrets Detection?

Hardcoded secrets in source code are one of the most common and dangerous vulnerabilities. A single exposed API key can lead to full account compromise, data breaches, and financial loss. Our engine continuously scans your codebase for 35+ secret patterns.

Detected Secret Types

Detection Methods

• Pattern Matching — 35+ regex patterns for known secret formats
• Entropy Analysis — Detects high-entropy strings that look like secrets
• Contextual Awareness — Understands variable names, assignments, config files

What is IaC Security?

Infrastructure-as-Code security scanning detects misconfigurations before deployment. Catch public S3 buckets, open security groups, privileged containers, and hardcoded credentials in your Terraform, Kubernetes, Docker, and Ansible files.

Supported Platforms

25+ Detection Rules

• Public S3 buckets / open storage
• Open security groups (0.0.0.0/0)
• Privileged containers / root users
• Unencrypted resources (RDS, storage)
• Hardcoded credentials in IaC
• Missing resource limits in K8s
• Host network / PID access
• HTTP (non-HTTPS) repositories

How It Works

The Security Factor Score is a weighted composite of 7 security pillars, each measuring a critical dimension of your application's security posture. The score makes security measurable, understandable, and actionable for both developers and executives.

Score Classifications

Why a Unified Score Matters

Most security tools give you a list of findings. Security Factor 365 gives you a number. That number tells you exactly where you stand, how you compare to your other applications, and whether you're improving or regressing over time.

• For Developers — Know immediately if your code changes improved or degraded security. Get specific guidance on which pillar needs attention.
• For Security Teams — Track portfolio-wide security posture across all applications. Identify the weakest links and prioritize resources.
• For Executives (CISOs) — One number on a dashboard. Trend lines showing improvement over quarters. Compliance status at a glance. Board-ready reports.

Scoring Methodology

Each pillar starts at 100 and loses points based on the severity and quantity of findings:

Score Tracking Over Time

Every scan saves a score snapshot. The portal shows trend lines, historical comparisons, and delta indicators so you can see the impact of each sprint on your security posture. The Security Matrix view shows all applications x all 7 pillars in a NASA-style grid for instant portfolio visibility.

Supported Frameworks

Also supports: FISMA, SLSA, CIS Benchmarks, CCPA, FINRA, FedRAMP, SAMATE

Why Agentic AI?

Traditional security tools generate reports. Our AI agents understand context, prioritize by business impact, generate fixes, and learn from your codebase. They work autonomously within your workflow — not as a post-scan afterthought, but as active participants in your security process.

How It All Connects

The four agents work together as a pipeline: the Triage Agent prioritizes what matters, the Remediation Agent generates fixes, the Copilot answers questions along the way, and the Threat Modeler provides the strategic view. All powered by the same AI engine, all sharing context about your application.

Why AI Security Scanning?

Traditional application security tools were built for a world without AI. They scan for SQL injection, XSS, and dependency vulnerabilities — but miss an entirely new class of threats introduced by LLMs, ML models, AI agents, and vector databases. Security Factor 365 is the first platform to include a dedicated AI Security scanner alongside traditional AppSec engines.

12 Detection Rules

AI Asset Discovery

While scanning, the engine automatically discovers and inventories all AI components in your codebase:

Example: Prompt Injection Detection

prompt = f"You are a helpful assistant. Answer this: {user_input}"
response = openai.ChatCompletion.create(
    model="gpt-4", messages=[{"role": "user", "content": prompt}]
)

system_prompt = "You are a helpful assistant. Only answer factual questions."
sanitized_input = sanitize_user_input(user_input, max_length=500)
response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": sanitized_input}
    ],
    max_tokens=1000,
    temperature=0.7
)

Compliance Mapping

What is DAST?

Dynamic Application Security Testing analyzes running applications from the outside — just like an attacker would. Unlike SAST (which reads source code), DAST sends actual HTTP requests, fuzzes inputs, and observes responses to find vulnerabilities that only manifest at runtime.

How SF365 DAST Works

DAST + SAST = ASPM Correlation

When DAST confirms a vulnerability that SAST also found in source code, the ASPM Correlation Engine elevates its priority — a finding validated by two engines is far more likely to be a real, exploitable issue. This dramatically reduces false positives.

What is it?

Container security covers the entire lifecycle of containerized applications — from base image selection through build-time scanning to runtime policy enforcement. As organizations adopt Docker and Kubernetes at scale, the attack surface expands with misconfigured containers, vulnerable base images, overprivileged workloads and secrets leaked into environment variables.

Why it matters

A single Dockerfile line like USER root or --privileged=true in a Kubernetes pod spec can turn a minor bug into a full cluster compromise. Container images inherit every CVE in their base layer, and one leaked AWS_SECRET_ACCESS_KEY in a build-arg can grant production access to anyone who pulls the image.

File types scanned

Key Capabilities

• Dockerfile best practices — detects USER root, :latest tags, ADD misuse, COPY . . overreach, missing HEALTHCHECK, multi-stage build opportunities.
• Exposed secrets in build args — credentials leaked via ARG / ENV get caught before they land in the image's immutable history.
• Kubernetes Pod Security Standards — validates privileged, runAsNonRoot, allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities.drop, seccompProfile.
• K8s misconfigurations — flags hostNetwork: true, hostPID: true, missing resource limits, default service accounts, secrets mounted as env vars.
• Image vulnerability scanning — cross-references base images and OS packages against NVD, GHSA and vendor feeds for known CVEs.
• Registry security — verifies image signing (Cosign / Sigstore), provenance attestation, tag immutability, trusted-registry allowlists.
• CBOM generation — Container Bill of Materials: a full inventory of every package, library and binary inside your images, exportable as SPDX or CycloneDX.
• Runtime behaviour hooks — via SENTINEL: unexpected egress, file-system writes, privilege escalations raise anomaly findings.

Sample findings SF365 raises

Standards & frameworks mapped

• CIS Docker Benchmark — Dockerfile and daemon configuration controls.
• CIS Kubernetes Benchmark — pod, cluster and control-plane hardening.
• NIST SP 800-190 — Application Container Security Guide.
• Pod Security Standards (Restricted / Baseline / Privileged).
• MITRE ATT&CK for Containers — techniques like T1610 (Deploy Container), T1611 (Escape to Host).

CI/CD integration

SF365's container checks run as part of both the Full scan and a standalone Container scan type. In CI, failing the build on any Critical Container finding (via quality gate) is a one-line policy. Slack and Jira integrations fire automatically when a new Critical lands — for containers, that usually means "stop the deployment, rotate the credential, rebuild the image."

What is SENTINEL?

SENTINEL is Security Factor 365's companion product for AI-powered log intelligence. It works standalone or fully integrated with SF365, providing real-time anomaly detection, attack chain correlation, and intelligent alerting that goes far beyond traditional SIEM rule matching.

Core Capabilities

Attack Types Detected

• Brute Force & Credential Stuffing — Multiple failed auth attempts, distributed attacks across IPs
• Data Exfiltration — Unusual data transfer volumes, access to sensitive endpoints, bulk data downloads
• Privilege Escalation — Unauthorized admin access, role manipulation, token abuse
• Slow & Low Attacks — Attacks spread over hours/days to evade rate limits and detection thresholds
• Configuration Tampering — Unauthorized changes to security settings, firewall rules, access policies
• Insider Threats — Anomalous behavior from authenticated users deviating from historical baselines

Offline Audit Mode

Security Log Audit as a Service — No agents, no installation, no access to client systems required. Simply upload log files and SENTINEL does the rest.

What is MCP?

The Model Context Protocol (MCP) server exposes SF365's entire security platform as 28 AI-callable tools. This means AI assistants like Claude, GPT, or custom agents can directly trigger scans, query findings, generate reports, and manage remediations — all through a standardized protocol.

28 Tools in 8 Categories

Beyond SBOM — The xBOM Family

Modern applications aren't just code and libraries. They include containers, ML models, AI components, and infrastructure. SF365 generates a complete inventory across all dimensions:

Why xBOM Matters

• Regulatory compliance — US Executive Order, EU Cyber Resilience Act, FDA guidance all require SBOM
• Vulnerability response — When a new CVE drops, instantly know which apps are affected
• License compliance — Track open-source licenses (MIT, GPL, Apache) across your portfolio
• Supply chain transparency — Full visibility into what's inside every artifact you deploy

What is OWASP?

The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation dedicated to improving the security of software. The OWASP Top 10 is the most widely recognized standard for web application security awareness, updated periodically based on real-world vulnerability data from hundreds of organizations.

OWASP Top 10 — 2021 Edition

How SF365 Maps to OWASP

Every finding detected by our SAST, SCA, DAST, and IaC engines is automatically mapped to the relevant OWASP category. The Compliance Hub shows your coverage percentage for each A01-A10 category, identifies gaps, and tracks remediation progress over time.

What is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. Version 4.0 (effective March 2024) introduces significant new requirements for application security.

Key Requirements for AppSec

What Changed in v4.0

• Customized approach — Organizations can now meet objectives through alternative methods
• Targeted risk analysis — Entities perform their own risk analysis for certain requirements
• Authentication enhancements — MFA for all access to the cardholder data environment
• Automated code reviews — Explicit acceptance of automated tools for code review (Req 6.2.4)
• Web application firewalls — Enhanced requirements for public-facing web applications

What is HIPAA?

HIPAA is a US federal law that mandates the protection of sensitive patient health information (PHI/ePHI). Any organization that handles electronic Protected Health Information must implement administrative, physical, and technical safeguards to ensure confidentiality, integrity, and availability.

Security Rule — Technical Safeguards

Why AppSec Matters for HIPAA

Application vulnerabilities are the #1 vector for healthcare data breaches. SQL injection, broken authentication, and misconfigured APIs can expose millions of patient records. HIPAA violations carry penalties up to $1.5 million per violation category per year.

What is GDPR?

The General Data Protection Regulation is the EU's comprehensive data privacy law, effective since May 2018. It governs how organizations collect, process, store, and protect personal data of EU residents. Non-compliance can result in fines up to €20 million or 4% of global annual turnover.

Key Principles for Application Security

Application Security & GDPR

GDPR doesn't prescribe specific technologies but requires "appropriate technical measures." This means vulnerability management, encryption validation, access control testing, and logging are all implicitly required. A data breach caused by a known, unpatched vulnerability is a clear compliance failure.

What is SOC 2?

SOC 2 is an auditing standard developed by the AICPA for service organizations. It evaluates an organization's information systems against five Trust Service Criteria (TSC). Type II reports cover a period of time (typically 6-12 months) and verify that controls are not only designed but also operating effectively.

Five Trust Service Criteria

Key Controls for Application Security

• CC6.1 — Logical access security software, infrastructure, and architectures
• CC7.1 — Detection and monitoring of security events and anomalies
• CC7.2 — Monitoring for anomalies indicative of malicious acts or compromises
• CC8.1 — Change management processes including authorization and testing
• CC3.2 — Risk assessment and identification of threats and vulnerabilities

What is NIST?

The National Institute of Standards and Technology (NIST) publishes cybersecurity frameworks used globally. NIST SP 800-53 provides a catalog of security and privacy controls, while the Cybersecurity Framework (CSF) 2.0 (released February 2024) provides a voluntary framework for managing cybersecurity risk.

CSF 2.0 — Six Core Functions

NIST 800-53 Key Control Families

• SA (System & Services Acquisition) — Secure development lifecycle, vulnerability analysis, code review
• SI (System & Info Integrity) — Flaw remediation, malicious code protection, vulnerability scanning
• RA (Risk Assessment) — Vulnerability monitoring and scanning, risk response
• CM (Configuration Management) — Baseline configuration, change control, least functionality
• AU (Audit & Accountability) — Audit events, content, review, analysis, and reporting

What is it?

A first-party Claude Code skill that wraps the SF365 REST API. Install once, then use natural language from any repository: "scan this repo", "list critical findings for the Billing app", "run SAST on application 7". Findings still persist in the full SF365 portal so your team keeps dashboards, compliance reports, and history — the skill is just the frictionless entry point.

Why it matters

Developers are no longer copy-pasting into standalone tools. They live inside Claude Code, Cursor and Copilot. Security that doesn't meet them there isn't adopted. The SF365 skill takes the enterprise-grade platform and makes it a one-command reach from the developer's prompt.

Inside the skill

Commands

• Authenticate — one-time login against your portal; JWT cached at ~/.sf365/credentials.json (0600 on Unix).
• List applications — GET /api/mobile/applications, ready to pick by name.
• Trigger a scan — POST /api/webhooks/generic; synchronous return with finding counts.
• List findings — filter by severity, opens a full view in the portal.

What is it?

A dedicated DB-backed registry of known-malicious open-source packages. Every SCA scan cross-references it against the dependencies declared in package.json, requirements.txt, *.csproj and friends. A match raises a Critical finding with full provenance: advisory id, source feed, summary, and reference URL.

How it stays fresh

The registry ships with a curated seed of documented incidents and is refreshed daily by SfMaliciousPackageSyncService, which queries OSV.dev for MAL-* advisories (OpenSSF's Malicious Packages dataset). Failures degrade gracefully: the local DB is always usable even if the feed is unreachable.

Seeded incidents (sample)

Ecosystems covered

• npm, PyPI, NuGet, Maven, RubyGems, crates.io, Go modules
• Match happens on (Ecosystem, PackageName); version ranges reserved for phase 2.
• Manual additions possible via the /malicious-packages page with a Sync Now button.

What is it?

A first-class feature in the SF365 portal that clones a well-known deliberately-vulnerable application and runs a full 12-engine scan against it with one click. Results are real ScanSessions — visible in the normal findings grid, Application 360 view, reports, and dashboards. No vendor claims you can't verify. The benchmark catalog also includes IoT-Goat, DVRF (Damn Vulnerable Router Firmware) and BLE CTF for verifying wireless / firmware detection.

Seeded benchmark suite

How the run works

• Clone — shallow git clone (--depth 50) via the platform's SourceProviderService.
• Apply — a linked Benchmark: X Application is created or reused.
• Scan — 12 engines run in parallel via the standard ScanOrchestrator.
• Persist — findings stream into dashboards, PDF reports, Slack/Jira if configured.

What it unlocks

• Live demos — "watch SF365 catch 47 real issues in WebGoat in 3 minutes."
• Regression tracking — if detection drops we see it before customers do.
• Marketing evidence — blog posts backed by verifiable numbers, not slideware.

What's inside

A ground-up rewrite of the SecretScanner pattern catalog: 91 high-signal regexes, organized by vendor, compiled once at static init so every scan line iterates ready-to-match automata instead of rebuilding patterns. Each pattern has a name, regex, vendor group, and severity — so findings land with clear attribution instead of "generic secret detected". The 2026 expansion adds 10 dedicated IoT / wireless cloud patterns aimed at firmware repositories and connected-device platforms.

Groups covered

AI APIs — a deliberate focus

Leaking an AI API key is a 2026 mistake. SF365 detects dedicated formats for OpenAI (sk- / sk-proj-), Anthropic (sk-ant-), Hugging Face (hf_), Replicate (r8_), Groq (gsk_), Gemini / Google AI Studio, Cohere and Pinecone. None of these show up in a generic "API key" regex.

IoT / wireless cloud — the 2026 firmware focus

Connected-device codebases routinely embed device-pairing material as constants. The new patterns catch:

• Azure IoT Hub Device SAS — HostName=*.azure-devices.net;SharedAccessKey=...
• Azure IoT Hub connection strings — IotHubConnectionString=... in source
• AWS IoT MQTT endpoints — *.iot.<region>.amazonaws.com
• GCP IoT device JWTs — mqtt.googleapis.com/projects/…/registries/…
• Particle.io access tokens, Tuya cloud secrets, SmartThings PATs
• HomeKit pairing setup codes — NNN-NN-NNN
• MQTT URLs with embedded credentials — mqtt://user:pass@broker
• ESP-IDF Wi-Fi credentials — CONFIG_ESP_WIFI_SSID / CONFIG_ESP_WIFI_PASSWORD

Precision engineering

• No bare GUIDs — the old Heroku rule was rewritten to require the heroku key name prefix, eliminating false positives on any UUID in source.
• Binary / vendor exclusions — node_modules/, .git/, vendor/, images, archives, fonts, lockfiles all skipped.
• Masked previews — findings never leak the full credential; first 4 + last 4 chars only.

Slack

After every scan, SF365 posts a colour-coded summary to an Incoming Webhook URL configured on the Integrations page. Critical > 0 renders red, High > 0 renders yellow, everything else renders green. Six fields are attached (Critical, High, Medium, Low, Total, Duration) plus a deep link to Application 360.

Jira Cloud

When a High or Critical finding is Confirmed in the portal, SF365 calls POST /rest/api/3/issue with Basic Auth (user email + API token) and creates a ticket in your configured project. Severity is mapped to priority (Critical → Highest). The CWE, CVE, OWASP category, file path and AI remediation summary go into the description as rich ADF content. The returned key and URL are stored on the Finding so the dashboard shows an inline Linked Jira issue badge.

Config surface

Fired from every scan pipeline

• Webhook endpoints — GitHub / GitLab / generic push events.
• Scheduled scans — CRON-driven background service.
• Benchmark runs — WebGoat and friends.
• Manual scans via the portal or the Claude Code skill.

The idea

IaC has hit the same maturity wall application code hit in 2011, when Heroku published the Twelve-Factor App. Teams ship Ansible playbooks, Terraform modules and Kubernetes manifests with wildly different levels of discipline — some versioned and tested, others hardcoded and unrepeatable. The SF365 12-Factor IaC Engine is a proprietary compliance domain that grades a codebase against ten auditable factors.

The ten factors we check

• 1 — Version Control — IaC must live under git. No .git/ → finding.
• 2 — Config Decoupled from Code — hardcoded IPs / hosts in playbooks are a smell.
• 3 — Multi-Environment Inventories — single-env trees or missing *.tfvars are flagged.
• 4 — Idempotency — raw shell: / command: without creates: / when: is a rerun bomb.
• 5 — Role Modularity — monolithic >200-line playbooks without roles/.
• 6 — Dependency Management — missing requirements.yml / versions.tf.
• 9 — Secrets Separation — plaintext credentials in non-vaulted YAML (Critical).
• 10 — Declarative Simplicity — Jinja chains with 3+ pipe filters are unmaintainable.
• 11 — Testing & Linting — no molecule/, no .ansible-lint, no .tflint.hcl.
• 12 — Documentation — roles without README.md.

How findings surface

Every violation lands as a regular SF365 Finding with Category = "12-Factor IaC", so you can filter the global findings grid, build a dashboard per factor, or export PDF / CSV compliance reports. The engine is wired into both the standalone IacTwelveFactor scan type and the Full scan, alongside the other 11 engines.

Supported IaC stacks

Why wireless deserves its own engine

Most AppSec platforms treat firmware repositories like any other codebase — they grep for SQL injection patterns and walk away. But the real risk in a connected device is rarely a SQL bug. It's a hardcoded SSID + PSK in a build flag, a BLE peripheral that pairs with Just Works, a Zigbee controller compiled with the well-known default trust-centre key ZigBeeAlliance09, an MQTT URL with embedded credentials, or a Bluetooth Classic stack still doing legacy pairing in 2026. SF365's WirelessScanner is purpose-built for these patterns and runs as the 12th engine in the standard ScanOrchestrator.

Six surfaces, 18 detection rules

What we look for

• Wi-Fi — WEP / WPA-TKIP, WPS still on, hardcoded SSID + PSK, open SSIDs left in production builds.
• Bluetooth Classic — default PINs (0000, 1234, 123456), legacy pairing without SSP, permanent discoverable mode.
• BLE — Just Works / NoInputNoOutput on devices that handle sensitive data, LE Secure Connections (LESC) disabled, GATT characteristics without encryption / authentication, hardcoded passkeys and bonding keys. Catches the static side of KNOB (CVE-2019-9506) and the BlueBorne / BleedingBit class.
• Sub-GHz RF — fixed-code remotes, hardcoded ISM frequencies (433.92 / 315 / 868 / 915 MHz), plain LoRa without LoRaWAN cryptography.
• NFC / RFID — MIFARE Classic still in production, UID-only authorisation.
• IoT transports — Zigbee with the default trust-centre key, MQTT broker URLs without TLS (mqtt:// port 1883), CoAP without DTLS.

Wireless Security Baseline — 24 controls

Findings ride a brand-new compliance framework synthesising NIST SP 800-153 (Wi-Fi), SP 800-121 Rev 2 (Bluetooth), SP 800-97 (802.1X) and IEEE 802.11i. Twenty-four auditable controls grouped as WIFI.01–07, BT.01–08, RF.01–03, NFC.01–02 and IOT.01–04, exportable as a dedicated PDF.

Dedicated dashboard at /wireless-security

Per-surface KPIs (Wi-Fi / BT / BLE / RF / NFC / IoT), severity breakdown, top wireless findings, baseline coverage progress, and the full 24-control table — all on a single page so a hardware / firmware lead has one view they can show to a board or auditor.

IoT / wireless secrets

The Wireless engine ships alongside 10 new patterns in the SecretScanner catalog: Azure IoT Hub Device SAS, Azure IoT connection strings, AWS IoT MQTT endpoints, GCP IoT device JWTs, Particle.io tokens, Tuya cloud secrets, SmartThings PATs, HomeKit pairing setup codes, MQTT URLs with embedded credentials, and ESP-IDF CONFIG_ESP_WIFI_SSID / CONFIG_ESP_WIFI_PASSWORD defines.

Verifiable detection

Three deliberately-vulnerable wireless / firmware targets ship in the Benchmarks catalog — IoT-Goat (OWASP), DVRF (Damn Vulnerable Router Firmware) (Praetorian) and BLE CTF (hackgnar) — one click to clone and run a full 12-engine scan against them.