Orthevs Engineering Lab · SEL

Connect security from target design to effectively verified controls.

The Security Engineering Lab brings assets, controls, findings, risks, detection, response, recovery and Evidence together in a Security Control Plane, with limited permissions, explicit scope and traceable decisions.

View use cases Explore 48 Factories

Documented target state · Concept / Architecture Baseline

Continuous Assurance

InputAssetsThreatsPolicies

Orthevs LabSELControl Plane

OutcomeControlsFindingsEvidence

Validation, incidents and recovery improve controls, rules and playbooks

Domain application · target architecture

Independent engineering environment

The Lab is designed as a complete domain application with a workspace, editors, models and SDK-like interfaces. Its Factories are the specialist tools; Engines handle processing and execution. Shared Contracts connect it with other Labs.

Develop security architectures, controls, policies and validation methods.

From Engineering Contract to verifiable outcome

01
Contract & Foundation
Requirements and rules select the domain foundation.
02
Lab Workspace
Models, editors and tools address the domain problem.
03
Factory & Engine
Specialist tools create artifacts and use suitable execution mechanisms.
04
Validation & Product
Tests, evidence and approvals lead to a versioned outcome.

The workflows and capabilities shown describe the documented target model. Check availability and maturity for each release and capability.

Mission and ambition

Security engineering connects prevention, detection, response and proof.

Security tools generate signals, but not yet a robust security model. SEL links targets and assets with expected controls, assessments, findings, risks, cases, incidents, remediation and Evidence. This makes visible what has been checked, what remains unknown and which decision follows from a result.

SEL is not a monolithic reimplementation of SIEM, EDR, IAM, PKI or scanners. Existing products are integrated through adapters and complemented with versioned security-as-code and security-as-a-product capabilities. Provider dependency remains contained behind open schemas and export contracts.

Read-only is the safe starting point. Mutating or offensive actions require a target, scope, time window, time-limited credentials, impact report, approval, kill switch and recovery path. A technical scan replaces neither a risk decision nor a legal compliance assessment.

Capability map

Twelve domains structure the Security Engineering Lab.

The domains organize responsibility and lifecycles. Within them, Factories deliver clearly bounded, versionable capabilities.

1 · SAF · SBF · SPF · TMF

Security Strategy & Architecture

Develop target architectures, threat models, baselines and policies as versioned security products.

2 · ADF · ASUF · RMF · VMF

Asset, Exposure & Vulnerability

Capture assets and attack surfaces, prioritize findings and track remediation through to re-test.

3 · AGF · ISF · PCF · SKSF

Identity, Access & Trust

Control identities, permissions, secrets, keys, PKI and trust relationships.

4 · ATF · DSBF · SCF · SSCF

Application & Supply Chain Security

Secure code, applications, dependencies, SBOM, provenance and release gates.

5 · CLSF · CSF · INSF · KSF

Infrastructure, Cloud & Platform Security

Assess hosts, cloud, Kubernetes and containers against baselines and exposure models.

6 · EWSF · ESF · NDF · ZTF

Network & Endpoint Defense

Bring together segmentation, endpoint controls, Zero Trust, and mail and web protection.

7 · DEF · STF · THF · TIF

Detection & Security Analytics

Operate telemetry, versioned detection rules, threat intelligence and hunting traceably.

8 · DFF · IRF · SOAF · SCMF

Security Operations & Incident Response

Coordinate alerts, cases, response, safe automation and forensics in one incident lifecycle.

9 · AEF · BSF · SEAF · SVF

Offensive Security & Validation

Use authorized assessments, emulation and breach simulation to verify control effectiveness.

10 · AEVF · CEF · PEF · RAF

Risk, Compliance & Privacy

Connect risks, control mapping, data protection and audit-ready Evidence with decisions.

11 · CCF · CRF · RRF · SEXF

Resilience & Crisis Security

Prepare and test cyber recovery, ransomware resilience, exercises and crisis coordination.

12 · AISF · CEF2 · OISF · SRF

Specialized & Emerging Security

Address AI, OT/IoT, cryptography, PQC and new threats in clearly scoped engineering profiles.

Use cases

SEL starts with the complete engineering problem.

The scenarios combine several Factories into one dependable flow. They describe the documented target state, not a product function that is already committed.

1Secure Provisioning

Secure a platform before and after provisioning

PEL obtains a signed OS image from OSEL, has SEL assess security profiles and preflight, and registers the finished cluster as a target again. Baseline and exposure assessments deliver findings and a traceable gate result.

Security before and after provisioning
Evidence across Lab boundaries
No direct database coupling

OSEL → PEL → SEL Gate → Provision → SEL Verify

2Exposure Management

From vulnerability to effectively verified fix

Asset discovery and vulnerability management produce a contextualized finding. Risk and ownership determine the remediation plan; PEL or OSEL execute the change, and SEL closes the finding only after an independent re-test.

Risk context instead of CVSS alone
Approval and change ownership
Resolved only after verification

ADF → VMF → RAF → RMF → PEL/OSEL → SVF

3SOC & Response

Coordinate detection, incident and recovery end to end

Permitted telemetry feeds tested detection rules. Case management prioritizes alerts, incident response documents decisions, forensics preserves Evidence, and cyber recovery coordinates restart and integrity checks.

Versioned detection rules
Chain of custody
Recovery with post-incident learning

STF → DEF → SCMF → IRF → DFF → CRF

4DevSecOps

Check software supply chains before release

Code, application, dependency and supply chain checks produce normalized findings and Evidence. Policies decide on release gates; exceptions have an owner, justification and expiry date.

SAST, DAST and SBOM
Provenance and signatures
Policy Gate with exception process

SCF → ATF → DSBF → SSCF → CEF → AEVF

End-to-end lifecycle

From the requirement to the controlled next state.

SEL covers preventive, detective and reactive security and feeds insights back into architecture, controls and playbooks.

1
Discover
Know assets and scope
Capture targets, owners, criticality, exposures and coverage.
2
Assess
Evaluate state
Run scope-limited checks with confidence, freshness and Evidence.
3
Architect
Design controls
Version threat models, baselines, trust boundaries and policies.
4
Implement
Roll out safeguards
Implement controls in a controlled manner through the responsible Labs and systems.
5
Validate
Verify effectiveness
Run security tests, re-tests and simulations against defined expectations.
6
Operate
Maintain posture
Continuously maintain coverage, exceptions, risks, findings and control states.
7
Detect
Recognize suspicious activity
Turn telemetry and tested rules into traceable alerts.
8
Respond
Contain incidents
Coordinate triage, containment, actions, communication and forensics.
9
Recover
Restore trust
Return systems, data and identities to a secure state with verification.
10
Improve
Embed lessons learned
Translate findings and incidents into better controls, rules, architecture and exercises.
11
Retire
Decommission securely
Control access, data, keys, Evidence and retention during dismantling.

Closed feedback loop

Validation, incidents and recovery improve controls, rules and playbooks. Insights are not merely documented; they flow, versioned, into the next engineering cycle.

Reference architecture

The security system itself is a critical trust boundary.

UI/API, Control Plane, isolated execution workers, targets and Evidence storage are separate zones, each with minimal permissions.

Layer 1 · Identity & Governance

Orthevs Platform

SSO, tenancy, IAM, policy, secrets, event bus and central audit context.

Layer 2 · Security Control Plane

SEL Core & API

Projects, targets, assets, controls, findings, risks, cases, incidents and approvals.

Layer 3 · Security Capabilities

SEL Factories

Architecture, assessment, detection, response, recovery, GRC and verification.

Layer 4 · Isolated execution

Worker, Adapter & Evidence

Scanners, SIEM, EDR, cloud, K8s, IAM, action runners and a protected Evidence store.

Read-only by default

Assessment starts without change permissions; actions require a new, explicit scope.

Fail closed

Cross-tenant or authorization errors stop the process and trigger audit and alert.

Unknown stays unknown

Missing coverage, rate limits or unreachable targets are not rated as compliant.

Evidence first

Findings and decisions remain linked to integrity-protected evidence.

Lab Core

Shared responsibilities keep the Factories integrable.

The Lab Core bundles the cross-cutting domain services; a Factory adds a capability without rebuilding these foundations in parallel.