Sophisticated attackers spend significant effort understanding defensive detection capabilities — studying what gets caught, identifying what gets missed, and operating deliberately in the gaps. The only effective response is a detection engineering program that is equally deliberate — constantly mapping coverage, constantly closing gaps, and constantly improving based on what hunts, incidents, and the threat model reveal. BLADE is that program.
Pillar Features — Problems BLADE solves
The Coverage Nobody Can See
The Rule Nobody Owns
The Gap That Keeps Getting Missed
The Noise Nobody Tuned
The Priority Nobody Set
The Rule That Never Got Tested
The Coverage Map That Lives in a Spreadsheet
The Hunt Finding That Goes Nowhere
The Incident That Repeats
The Tuning Decision Nobody Recorded
The Program Nobody Can Measure
The Detection That Degraded Silently
What BLADE delivers
Every Capability. Every Workflow. Every Detail of How BLADE Engineers Your Detection Program.
Every Rule Known. Every Rule Owned. Every Rule Managed Through Its Full Lifecycle.
A detection program without a rule registry is a collection of rules without a program. BLADE's detection rule registry is the authoritative catalog of every detection rule across every source tool in the stack — not just the rule logic, but the full context that makes the rule manageable: what technique it detects, who owns it, when it was last validated, what its current false positive rate is, and where it sits in its lifecycle. The registry turns a collection of individual rules into a managed, measurable detection program.
Every detection rule in BLADE carries a structured record — rule name, description, the MITRE ATT&CK tactic and technique it is designed to detect, the source tool it is deployed in, the owner responsible for its maintenance, the date it was last validated, its current status in the lifecycle, and its performance metrics including false positive rate and true positive rate. Rules are imported from connected source tools or created directly in BLADE — with every creation, modification, and status change recorded in an immutable change history. The lifecycle status tracks every rule through five stages — Proposed, In Development, Testing, Active, and Deprecated — with transition criteria defined for each stage and transition history preserved for every rule. Nothing enters production without a documented development and testing record, and nothing gets deprecated without a documented reason.
Know Exactly What Your Detection Program Covers. And What It Doesn't.
Most SOCs have a general sense of their detection coverage — the tools deployed, the rules written, and a vague confidence that the major techniques are covered. BLADE replaces that general sense with a precise, current, documented coverage map — every active rule mapped to the MITRE ATT&CK technique it is designed to detect, every gap made explicit, and every coverage change tracked over time. The map is not a point-in-time assessment — it updates dynamically as rules are created, modified, and deprecated.
Every rule in the BLADE registry carries a MITRE ATT&CK tactic and technique mapping. The coverage map aggregates those mappings into a visual heatmap — showing which techniques have active detection coverage, which have rules in development or testing, and which have no coverage at all. Techniques with multiple active rules show as deeply covered. Techniques with a single rule show as thinly covered and surface as candidates for additional engineering. Techniques with no rule show as explicit gaps. The coverage map filters by source tool, by tactic, by actor TTP from CIPHER, and by TIME gap register priority — giving engineering teams the ability to focus on the coverage dimensions most relevant to their current priorities. Coverage trends show how the map has changed over time — whether the program is expanding, stable, or degrading.
Every Gap Has a Request. Every Request Has an Owner. Every Owner Has a Deadline.
Detection gaps do not close themselves. They close when an engineer writes a rule — and that happens consistently only when there is a structured pipeline from gap identification to engineering work. BLADE's detection request pipeline is that structure — a formal intake process that captures every detection gap identified by TIME, PROWL, SHIELD, and CIPHER, converts it into a prioritized engineering request, assigns it to an owner, and tracks it through development, testing, and deployment to closure.
Detection requests enter BLADE from four sources — TIME gap register entries for undetected TTPs in the threat model, PROWL True Positive findings for techniques confirmed present but lacking a detection rule, SHIELD post-incident findings for techniques used in confirmed incidents that were not detected, and CIPHER TTP coverage gap alerts for actor techniques with no corresponding detection coverage. Every request carries the originating source, the technique to be detected, the threat actor attribution where available, the priority level, the environmental context from the originating pillar, and the analyst who identified the gap. Requests are assigned to engineers with expected completion timeframes. Development progress tracks through the five lifecycle stages. Completed rules close the originating request and update the coverage map — closing the loop between gap identification and gap closure.
Noise Is Not Coverage. BLADE Makes Sure Every Rule Earns Its Place.
A detection rule that generates so much noise it gets suppressed is not a detection — it is a blind spot with extra steps. False positive management is not a cleanup task for when things get noisy — it is an ongoing engineering discipline that keeps every active rule in the registry generating actionable signal rather than analyst fatigue. BLADE tracks false positive rates for every rule, surfaces rules that are degrading in quality, and maintains a structured tuning log that ensures every suppression and threshold change is a documented engineering decision rather than an undocumented workaround.
Every active rule in BLADE tracks its false positive rate — updated from alert disposition data fed by FLARE as analysts triage and close alerts. Rules whose false positive rate exceeds defined thresholds surface automatically as tuning candidates in the engineering queue. The tuning log captures every modification made to an active rule — threshold changes, suppression additions, logic adjustments, and field modifications — with the engineer who made the change, the reasoning documented, the date, and the false positive rate before and after the change. Rules that have been tuned multiple times in a short period surface as candidates for fundamental redesign rather than incremental adjustment. Suppressions that have been in place for longer than a defined period surface for review — preventing permanent blind spots from accumulating under the guise of noise management.
A Rule That Has Not Been Tested Has Not Been Validated. BLADE Ensures Both.
Detection rules deployed directly to production without testing are assumptions dressed as coverage. A rule may be logically sound and technically correct but still fail to detect the technique it was designed to catch — because the log format changed, because the behavior manifests differently in the specific environment, or because a subtle logic error only surfaces against real telemetry. BLADE makes testing a required stage in the rule lifecycle — every rule validated before it is declared active coverage, and every active rule periodically revalidated to confirm it still works as intended.
Every rule in BLADE moves through a Testing stage before it can be promoted to Active. The testing record captures the test methodology — the simulated or historical telemetry used, the expected alert behavior, the actual alert behavior, the analyst who performed the test, and the date. Rules that produce the expected alert behavior in testing are promoted to Active. Rules that fail testing return to In Development with the failure documented and the engineer notified. Active rules are subject to periodic revalidation cycles — scheduled validation reviews that confirm the rule is still generating expected alerts against current telemetry. Validation failures on active rules surface immediately as critical issues — a rule that was working and has stopped generating alerts represents a silent coverage gap that requires immediate investigation.
Measure the Program. Prove the Program. Improve the Program.
A detection engineering program that cannot be measured cannot be managed — and cannot be defended when leadership asks whether the investment in detection tooling and engineering time is producing a coverage program that actually catches threats. BLADE captures the operational data that turns a collection of individual rules into a measurable, improvable, defensible program — coverage trends, false positive rates, engineering velocity, request pipeline health, and detection impact — giving engineering leads the data to run the program and CISOs the evidence to justify it.
Every rule created, modified, deployed, and deprecated in BLADE contributes to a growing analytics dataset. Coverage trend tracks the expansion, contraction, or stability of ATT&CK technique coverage over time — broken down by tactic, by source tool, and by threat actor TTP relevance. Engineering velocity measures how quickly detection requests move from intake to active deployment — identifying bottlenecks in the development pipeline and surfacing requests that have been in the queue too long. False positive rate trends show whether the overall quality of the detection program is improving or degrading. Detection impact measures how many confirmed incidents and True Positive hunt findings originated from BLADE rules — demonstrating the operational value of the engineering program in concrete terms. The complete analytics picture feeds directly into SCOUT's executive reporting layer.
Every Pillar Makes BLADE Better. BLADE Makes Every Pillar More Effective.
Body: Detection engineering does not exist in isolation from the rest of the SOC — it is the capability that every other pillar either feeds with gap intelligence or depends on for detection coverage. BLADE is the engineering layer that receives intelligence from FLARE, PROWL, SHIELD, TIME, and CIPHER, turns it into detection coverage, and feeds that coverage back to the pillars that depend on it — creating a continuous feedback loop where every operational finding improves the detection program and every detection improvement improves operational outcomes.
How It Works: BLADE receives detection gap intelligence from five sources simultaneously. FLARE feeds alert disposition data — true positive and false positive rates that drive tuning priorities. PROWL feeds True Positive hunt findings — confirmed techniques that should have been detected but were not. SHIELD feeds post-incident findings — techniques used in confirmed incidents that had no detection coverage. TIME feeds gap register entries — high-priority undetected techniques from the threat model. CIPHER feeds actor TTP coverage gaps — techniques used by registered actors with no corresponding detection rule. Every source contributes to the detection request pipeline and the coverage map. BLADE's output feeds back to FLARE as deployed rules that improve alert quality, to TIME as coverage updates that close gap register entries, and to PROWL as coverage notifications that redirect hunting effort away from techniques that are now detected.
Detection-as-Code Meets Detection Engineering Operations. BLADE and OpenTide, Connected.
OpenTide — Open Threat-Informed Detection Engineering — is a comprehensive open-source framework built to enable Threat and Detection Modelling and Detection-as-Code in a unified workflow. It is the open-source reference for Detection Engineering teams looking to adopt Detection-as-Code, Threat and Detection Modelling, and modern DevOps workflows. BLADE integrates with OpenTide to connect SCOUT's operational detection engineering program to OpenTide's Detection-as-Code pipeline — combining BLADE's lifecycle management, coverage mapping, and gap prioritization with OpenTide's standardized schema, CI/CD deployment architecture, and community-shared threat object library.
OpenTide aims at measuring and expanding detection coverage, and its rule deployment engine is fully extensible and supports multiple platforms in parallel, leveraging all the technology features and native query language. BLADE's integration with OpenTide operates across three dimensions. First, detection requests generated in BLADE from TIME, PROWL, SHIELD, and CIPHER can be exported in OpenTide's standardized schema — enabling detection rules developed against those requests to be built, version-controlled, and deployed through OpenTide's CI/CD pipeline rather than manually pushed to individual source tools. Second, rules developed and deployed through OpenTide's pipeline import their metadata back into BLADE — updating the rule registry, the coverage map, and the lifecycle status automatically as rules move through the OpenTide development and deployment workflow. Third, OpenTide's ShareTide community repository of over 200 vetted threat objects from the European Commission CSOC is available as a detection content library within BLADE — surfacing community-validated detection logic as starting points for engineering requests that target common techniques, accelerating rule development without requiring every rule to be built from scratch.
How BLADE works
From Environment Map to Closed Gap — Every Step Structured, Every Output Operational.
Gap Identified
Request Created
Request Prioritized
Rule Designed
Rule Developed
Rule Tested
Rule Deployed
Performance Monitored
Rule Tuned
Rule Revalidated
Coverage Map Updated
Program Measured
If your detection program has rules nobody owns, coverage gaps nobody tracks, and a tuning log that exists only in someone's memory — BLADE was built for exactly that problem. Here are the questions detection engineers, hunt leads, and security leaders ask most often about how BLADE turns individual rule writing into a structured, measurable, continuously improving detection engineering program.
BLADE — Behavioral Logic and Adversary Detection Engineering — is SCOUT's detection engineering pillar. It gives SOC teams a structured platform to manage the full detection rule lifecycle, map coverage against the MITRE ATT&CK framework, receive and prioritize detection gap requests from every other SCOUT pillar, track false positive rates and tuning decisions, validate rules before deployment and periodically after, and measure the program's improvement over time. BLADE transforms detection engineering from a reactive, ad hoc activity into a structured, measurable program.
Managing rules in a SIEM is a technical task. BLADE is a program. The SIEM stores and executes the rule logic — BLADE manages everything around it: the lifecycle from proposal to deprecation, the coverage map that shows what the rules collectively cover, the request pipeline that ensures gaps get closed, the tuning log that documents every modification, the validation process that confirms rules work before deployment, and the analytics that measure whether the program is improving. A SIEM tells you what rules you have. BLADE tells you whether those rules constitute an effective detection program.
Every rule in BLADE moves through five defined stages — Proposed, In Development, Testing, Active, and Deprecated. Proposed captures the initial gap identification and design intent. In Development tracks the rule build process. Testing validates that the rule generates expected alerts before deployment. Active marks rules that are deployed, validated, and providing real coverage. Deprecated documents rules that have been retired with the reason and date. Every stage transition is recorded with timestamp and attribution — ensuring a complete lifecycle history for every rule in the registry.
Detection requests enter BLADE automatically from five sources. TIME routes gap register entries for undetected TTPs in the threat model. PROWL routes True Positive hunt findings for techniques confirmed present but lacking detection coverage. SHIELD routes post-incident findings for techniques used in confirmed incidents without detection. CIPHER routes actor TTP coverage gap alerts for techniques used by registered actors with no corresponding rule. FLARE feeds alert disposition data that surfaces techniques appearing in manual triage without automated detection. Every source contributes to the engineering pipeline automatically — no manual translation required.
Every rule in the BLADE registry carries a MITRE ATT&CK tactic and technique mapping. The coverage map aggregates those mappings into a dynamic heatmap showing which techniques have active detection coverage, which have rules in development or testing, and which have no coverage at all. The map updates in real time as rules are deployed, modified, and deprecated — ensuring it always reflects current active coverage rather than a point-in-time snapshot. The map filters by source tool, tactic, actor TTP from CIPHER, and TIME gap priority — giving engineering teams the ability to focus on the dimensions most relevant to their current work.
Every active rule in BLADE tracks its false positive rate — updated continuously from alert disposition data fed by FLARE as analysts triage and close alerts. Rules exceeding defined FP thresholds surface automatically as tuning candidates in the engineering queue. Every tuning action — threshold change, suppression addition, logic adjustment — is documented in the tuning log with the engineer, reasoning, date, and before/after metrics. Long-standing suppressions surface periodically for revalidation. Rules tuned multiple times in a short period are flagged as redesign candidates — indicating a structural problem that incremental tuning will not resolve.
Every rule must pass a structured testing stage before it can be promoted to Active status. The test validates that the rule generates expected alert behavior against simulated or historical telemetry representing the technique being detected. The test record captures the methodology, the telemetry used, the expected behavior, the actual behavior, and the outcome. Rules that pass are promoted to Active. Rules that fail return to In Development with the failure documented. Active rules undergo periodic revalidation to confirm they still generate expected alerts against current telemetry — protecting against silent coverage degradation when log formats or data sources change.
Silent coverage degradation occurs when a detection rule continues to exist in the registry and appear in the coverage map while actually generating no alerts — because a log format changed, a data source was modified, or a pipeline configuration was altered. The rule appears healthy but provides no actual detection capability. BLADE prevents this through periodic revalidation cycles — scheduled confirmations that every active rule is still generating expected alerts against current telemetry. Rules that fail revalidation surface immediately as critical issues — the coverage map removes them from active coverage until the failure is investigated and resolved.
BLADE and PROWL operate in a continuous feedback loop. PROWL routes True Positive hunt findings to BLADE as detection requests — every confirmed technique that should have been detected but was not becomes an engineering priority. BLADE routes coverage updates to PROWL when new rules are deployed — notifying PROWL that a previously uncovered technique now has detection coverage and redirecting hunting effort toward techniques that remain uncovered. The loop ensures that hunting effort always focuses on genuine gaps rather than techniques already covered by active rules.
TIME routes gap register entries to BLADE as detection engineering priorities — every undetected TTP in the threat model becomes a request in the engineering pipeline with priority, actor attribution, and environmental context. BLADE routes coverage updates back to TIME as rules are deployed — closing gap register entries and updating the coverage validation picture that TIME maintains. The connection is bidirectional and automatic — TIME tells BLADE what to build, and BLADE tells TIME what has been built.
SHIELD routes post-incident findings to BLADE as detection requests — every technique used in a confirmed incident that generated no alert becomes an engineering priority with the incident attribution providing the context and urgency that drives prioritization. BLADE's active rule inventory is available in the SHIELD incident workspace — allowing the response team to confirm which techniques in the incident were detected by rules and which were only identified through hunting or manual investigation. Post-incident detection gaps receive elevated priority in the BLADE queue — the same technique appearing in multiple incidents without detection represents a critical engineering failure that requires immediate attention.
BLADE feeds a comprehensive set of program analytics into SCOUT's reporting layer — ATT&CK coverage trend by tactic and source tool, engineering velocity from request intake to active deployment, false positive rate trend across the full rule inventory, detection impact rate measured by incident and hunt finding attribution, request pipeline health showing queue depth and age distribution, and revalidation compliance showing the percentage of active rules within their scheduled validation cycle. Reports are available on demand or on a scheduled basis and feed directly into SCOUT's executive dashboard — giving CISOs the evidence to demonstrate detection program maturity, justify engineering investment, and brief the board on the organization's detection capability with data rather than narrative.
Every rule in the BLADE registry carries its full development and tuning history — the design intent, the behavioral indicators it was built to detect, every modification made, every test result, and every revalidation outcome. When a detection engineer leaves the team, every rule they wrote, every tuning decision they made, and every test they ran stays in the registry — fully documented, fully attributable, and fully available to the engineer who inherits their rules. The detection program retains the knowledge even when it loses the person, and every new engineer who joins the team inherits the accumulated engineering history of every rule that came before them.
BLADE sits at the engineering core of the SCOUT detection program — receiving gap intelligence from every pillar and returning coverage improvements to every pillar that depends on them. FLARE feeds alert disposition data that drives tuning priorities. PROWL feeds True Positive findings that become detection requests. SHIELD feeds post-incident findings that become engineering priorities. TIME feeds gap register entries that become the engineering roadmap. CIPHER feeds actor TTP coverage alerts that ensure the detection program keeps pace with the intelligence picture. Every pillar makes BLADE better. And every rule BLADE deploys makes every pillar more effective — because better detection coverage means fewer True Positives that only hunting finds, fewer incidents that only post-mortem reveals, and a threat model with fewer critical gaps left open.
Every detection program has gaps. The question is not whether they exist — it is whether the program is designed to find them, prioritize them, close them, and prevent new ones from opening silently. Most detection programs are not. Rules get written reactively, tested informally, tuned inconsistently, and never revalidated after deployment. Coverage is tracked in a spreadsheet that is always out of date. Engineering priorities are set by whoever asks most loudly rather than by what the threat model says matters most. And somewhere in that collection of underengineered rules and undocumented suppressions, there is a technique your most likely threat actor uses — and your detection program has no coverage for it.
BLADE was built to change that — not by making detection rule writing easier, but by making detection engineering a disciplined, measurable, continuously improving program. A program where every rule has a lifecycle and every stage of that lifecycle has defined criteria. Where every gap identified by a hunt, an incident, a threat model, or an actor TTP inventory automatically becomes an engineering work item with an owner and a deadline. Where every deployed rule is validated before it is counted as coverage and revalidated periodically to ensure it stays that way. Where every tuning decision is documented so no suppression ever creates a blind spot that nobody knows exists.
The feedback loop that makes BLADE continuously improving is the integration with every other SCOUT pillar. PROWL finds a True Positive — BLADE gets a detection request. SHIELD closes an incident — BLADE gets a post-incident gap. TIME updates the threat model — BLADE gets a prioritized engineering roadmap. CIPHER profiles a new actor — BLADE gets the TTP coverage gaps. Every operational finding from every pillar feeds the engineering queue. Every rule BLADE deploys improves the coverage picture that every pillar depends on. The program does not improve occasionally, when someone remembers to update the backlog. It improves continuously, because the platform makes every operational event an engineering input.
If your detection program is a collection of rules rather than an engineered capability — BLADE is where the program starts.
SCOUT is available now. Watch the full platform demonstration and see BLADE in action — from detection request intake to rule lifecycle management, ATT&CK coverage mapping to false positive tuning, rule validation to program analytics. One hour. Seven pillars. Everything your SOC has been missing.
Operate Ahead of the Threat.
SCOUT is a unified SOC platform with seven purpose-built pillars — covering every workflow from alert triage to detection engineering — built by analysts, for analysts, at the speed modern threats demand.
Rated 4.9 of 5
SCOUT © All rights reserved
