Core Concepts
This page defines the fundamental building blocks of the S4E platform. Understanding these concepts is essential for working effectively with the system, whether you are running scans, reviewing findings, or managing a partner portfolio.
Assets
An asset is any digital resource that your organization wants to monitor and protect. Assets are the foundational objects in S4E - everything starts with an asset.
Common asset types include:
- Domains - e.g.,
example.com - Subdomains - e.g.,
api.example.com,staging.example.com - IP Addresses - individual IPs or CIDR ranges
- Web Applications - full URLs representing specific applications
- APIs - documented or discovered API endpoints
Assets can be added manually, imported in bulk, or discovered automatically through crawling and reconnaissance. Each asset goes through an ownership verification process to ensure that users can only scan resources they are authorized to test.
Assets support tagging and classification to help organize large inventories by business unit, environment (production, staging), criticality level, or any custom taxonomy.
Note
Ownership verification is mandatory before any scan can be run against an asset. This protects against unauthorized scanning of third-party infrastructure.
Scans
A scan is a security assessment executed against one or more assets. Scans are the primary mechanism for discovering vulnerabilities and exposure points.
S4E supports multiple scan types, including:
- Web vulnerability scanning
- Port and service discovery
- SSL/TLS configuration analysis
- DNS record enumeration
- Directory and file fuzzing
- API endpoint discovery
- Technology fingerprinting
AI-Created Scans
S4E includes an AI-powered scan builder that lets you create custom security checks using natural language. Simply describe what you want to test, and the AI generates and executes the scan code for you.
Examples of what you can create:
- Test most commonly used passwords in your organization
- Chain multiple attacks like a hacker would
- Detect your 3rd party app versions
- Detect exposed admin panels
- Check for SQL injection on login pages
- Detect public file upload areas
No coding knowledge required. Describe your need, the AI creates the code, runs it in the S4E engine, and delivers real-time results you can review and refine.
Scan Triggers
Scans can be:
- On-demand - triggered manually by a user or via API
- Scheduled - configured to run automatically at defined intervals
- Event-driven - triggered by external events or conditions through the trigger service
Each scan execution produces a set of findings and records detailed metadata about the scan lifecycle (queued, running, completed, failed).
Crawler
The S4E crawler automatically discovers pages, endpoints, and resources across your web assets. It navigates through your application like a real user, mapping out the full attack surface including hidden paths, API routes, and dynamically generated content. Crawler results feed directly into the scanning pipeline, ensuring comprehensive coverage.
Enrichment
After scans and crawling are complete, S4E enriches the collected data with additional context to improve accuracy and prioritization. Enrichment adds metadata such as technology stack detection, known CVE mappings, geolocation, WHOIS data, certificate details, and third-party threat intelligence feeds. This process turns raw scan output into actionable, context-rich findings.
Findings
A finding is an individual security issue discovered during a scan. Each finding represents a specific vulnerability, misconfiguration, or exposure point on a particular asset.
A finding includes:
- Title and description - What the issue is
- Severity - Critical, High, Medium, Low, or Informational
- Security Score - A composite score where lower values indicate higher risk
- Affected asset - The asset where the issue was found
- Evidence - Technical details, request/response data, or proof of the issue
- Remediation guidance - Steps to resolve the issue
- Status - Open, In Progress, Request for Approval, Fixed, False Positive, Accepted Risk, Support Ongoing, No Action Required, Reopened
Findings are deduplicated across scan runs, so if the same vulnerability is detected in consecutive scans, it is tracked as a single finding with an updated "last seen" timestamp rather than creating duplicates.
Severity and Security Score
S4E uses a two-layer classification system for findings:
Severity
A categorical rating based on the technical impact of the vulnerability:
| Level | Description |
|---|---|
| Critical | Immediate exploitation risk with severe impact (e.g., RCE, SQL injection) |
| High | Significant risk that should be addressed urgently |
| Medium | Moderate risk, typically requiring action within a defined SLA |
| Low | Minor issues with limited direct impact |
| Info | Informational observations that may warrant awareness but not remediation |
Security Score
A numeric score (0-100) that reflects the overall security posture of an asset or organization. A lower security score indicates higher risk.
The score accounts for:
- Asset criticality - A vulnerability on a production payment gateway has more impact than the same issue on an internal staging server.
- Exposure level - Internet-facing assets carry more weight than those behind a VPN.
- Exploitability - Known exploits in the wild decrease the score further.
- Business context - Compliance requirements and data sensitivity adjustments.
The security score enables teams to prioritize remediation efforts based on actual organizational risk rather than raw technical severity alone.
Actions
An action is a discrete, executable operation performed in response to a finding or security event. Actions bridge the gap between identifying a problem and resolving it.
Examples of actions:
- Send an email or Slack notification to the asset owner
- Create a ticket in Jira, ServiceNow, or another issue tracker
- Execute a remediation script on the affected system
- Update a firewall rule or WAF configuration
- Tag or reclassify an asset based on findings
Actions can be:
- Manual - Triggered by a user from the findings interface
- Automatic - Triggered by rules when specific conditions are met (e.g., "when a Critical finding is detected on a production asset, create a Jira ticket")
- AI-generated - Suggested by the platform's AI engine based on the finding context and historical remediation patterns
Every action execution is logged with a full audit trail, including who initiated it, when it ran, and what the outcome was.