2026 workshop program

• STPA-Sec provides a system-theoretic framework that guides red teams toward high-value losses by identifying critical system responsibilities, unsafe control actions, and required reconnaissance.
• It shifts red team focus from isolated GenAI component attacks to a holistic view of the system, while also helping blue teams anticipate attacks and design better mitigations.
• Wargaming with STPA-Sec reveals gaps in security mitigations and highlights areas requiring further research, analysis, or technical development to better assess attack risk.

This talk presents, in detail, the STPA journey that Meta has been on over the last year.

• Initial interest, attending a STAMP workshop, online training.
• Revisiting two significant software weaknesses to ask the question “could STPA have helped to catch this?”
• Applying STPA to a recent design.
• Getting buy off and hosting an initial STPA training class.
• Learnings from the training class and next steps.

• Aviation Industry needs to adapt a systems thinking based model of the world (From linear causality to loops and interaction) that copes with existing dynamic contexts of operations and accounts for new modes of automation and complexity.
• Greater focus should be given to the need to intentionally design safe systems (processes) to control safety outcomes rather that avoid failures.
• Increase SMS maturity by adopting systems thinking methodologies such as STAMP for Safety Risk Management control and Safety Assurance to transition from component focus to controlling interactions.

• This work demonstrates the value of applying STPA as a system-level safety analysis method that goes beyond traditional component-based failure thinking.
• The application of STPA shifted the focus toward control structures, system interactions, and feedback, leading to a deeper understanding of safety-related behavior.
• The results showed that many unsafe control actions arise from missing or incomplete system knowledge rather than individual human error.
• Overall, the work demonstrates that integrating STPA with existing safety processes can improve hazard identification and support more robust safety decisions.

• We first tried a tool-first approach, but it did not scale: tools diverged, assumptions drifted, and outputs became inconsistent.
• We moved to a spec-first model: one plain-text JSON/YAML format that is both human-readable and machine-readable.
• Because artifacts are Git-native, teams can use pull requests, diffs, reviews, and history for auditable collaboration.
• Typed links provide end-to-end traceability (UCA/scenario to constraints, requirements, tests, evidence) and enable fast tooling: validators, VS Code support, docs, visualization, and AI-assisted analysis

1. Looks at how the STPA process can be used today as a method of compliance to the current safety relevant airworthiness regulations in FAA Part 25.
2. Draws upon past work to allow risk based considerations covering 25.1309, 25.1302, and 25.1322

• STPA applied to flight-test risk management for a self-reconfiguring fighter flight-control system: six system-level hazards, 28 unsafe control actions across five controllers (nine of them belonging to the pilot and test director), and an unbroken chain from hazard to flight-test point.
• Reconfiguration met its 1 s activation deadline in all six simulator cases — and still reached 6.2 g against a 4 g bound and departed the validated envelope in 100% of sampled conditions. Reducing the fault magnitude made the peak load worse, not better.
• Step 4 explained why: normal acceleration was measured, telemetered and recorded, but never routed to the engagement-inhibit logic. Nothing had failed

• Discussion on how to strategically implement STPA in a Design Organization
• Preliminary results, including Control Structure and Controller Constraints
• How we used the Controller Constraints directly to generate test cases
• Feedback and edge cases reported by the Avionics team

• Applies standard STPA to CI/CD database validation decisions, focusing on when a “green” validation result is trustworthy enough to support downstream use or version promotion.
• Reframes flaky or misleading validation outcomes as feedback and process-model problems rather than only test-script or validation-tool failures.
• Models a representative open-source pipeline as concrete implementation examples.
• Derives supervisory decision logic for checking completeness, freshness, applicability, readiness, and validation-window integrity before accepting validation evidence.

As an STPA & CAST practitioner, have you ever wondered how to accelerate the mental model shift needed for others to develop a systems safety view of the world?
STPA reveals a missing dimension in how we reason about complex systems, moving us beyond failures and linear causality to see control, interactions, feedback and emergence.
Drawing on interviews with 18 practitioners across nine disciplines, this talk explores what triggers that internal “aha” moment and how we can deliberately create it in others, helping our teams and organisations see what they couldn't see before.

1. Aligns STPA into the current ARP-4761A safety assessment process
2. Shows how STPA can supplement the existing ARP-4761A process and develop new and interesting results based around a worked example
3. Provides insights into the forthcoming AIR-6913 STPA guidance from SAE Intl

• Mercado Libre's internal platform powers 60,000+ microservices for 18,000+ developers
• Systems engineering was introduced to SRE operations with a focus on finding insights and providing mitigations for code already in production
• A very simple STPA analysis resulted in unveiling basic unknown unknowns that empowered AI analysis of all services used company wide: asking the right questions proved to be a very effective form of prompt engineering

• CAST reveals interacting deficiencies in component-state control, configuration change, readiness, authorization, and flight consequence control beyond the seal failure.
• The analysis identifies discontinuities across launch acceptance, verification, authorization, and release decisions.
• Comparison with the official investigation confirms its contributing factors and recommendations, while CAST adds common acceptance baselines, cumulative assurance, operational verification, and evidence preservation.
• The study converts accident evidence into traceable constraints and practical controls for safer launch operations.

1. Applied STPA to a hybrid hydrogen–electric aircraft architecture to identify hazards and critical safety parameters for health monitoring.
2. Modeled a hierarchical control structure; identified and classified Unsafe Control Actions using ASTM F3230 standard for classifying severity levels.
3. Revealed interaction-driven hazards that traditional component-based methods often miss.
4. Derived controller constraints and critical monitoring parameters (pressure, temperature, flow rates, SOC/SOH, latency) for health management and certification planning.

• STPA reveals cross-organizational safety risks arising from mismatched assumptions, unclear control responsibilities, inadequate feedback, and timing dependencies.
• A Highway Pilot example shows how UCAs and loss scenarios reveal safety-critical weaknesses in control and feedback paths spanning AI-enabled perception, decision-making, actuation, and vehicle interfaces.
• STPA-derived safety constraints are translated into interface requirements, responsibility allocation, explicit assumptions, and verification expectations.
• STPA results strengthen integration decision-making, safety assurance, and interface governance across boundaries between OEMs, ADS developers, and Suppliers.

• STPA was performed in MBSE using DESE-CAMEO during Preliminary Design on a military rotorcraft platform.
• General program structure and intro to STPA are provided, followed by how STPA was performed, including control structure overview and example hazards, UCAs, and derived safety requirements. Observations follow.
• STPA identified safety requirements earlier than traditional safety processes might.
• MBSE’s single central repository of SE data created opportunities that would not have been feasible in traditional SE ecosystems.
• STPA use cases later in the acquisition lifecycle are also explored in addition to the main focus on the PD phase.

• Identifies a key gap in STPA-SEC: Hazard analysis identifies constraints but provides limited guidance for engineering controllers that enforce them during operations.
• Introduces controller engineering: Demonstrates how STPA-SEC outputs can be transformed into hierarchical cyber-risk controllers enabling secure enterprise digital operating environments.
• Extends STPA-SEC for resilience: Shows how continuous feedback, monitoring, and adaptive control strengthen mission assurance across enterprise, IT, OT, and cyber-physical systems.
• Advances STPA-SEC research: Positions controller engineering as the next evolution of STPA-SEC, bridging hazard analysis with cyber risk engineering.

• This talk proposal aims to present the results of integrating STPA into a DevSecOps pipeline to derive safety, cybersecurity, and data privacy requirements with regulatory traceability, in which regulatory non-compliance is modeled as an unacceptable loss.
• The integration was evaluated through a case study of the DevSecOps processes responsible for the development, verification, deployment, and maintenance of SisAPEC, an LLM-supported healthcare platform deployed across Primary Health Care Units and a hospital within the Brazilian Unified Health System (SUS). The analysis identified Unsafe Control Actions (UCAs) and causal scenarios in which no individual system component failed.

Applies STAMP methods to coercive psychiatric treatment in Canada, using a 2026 open-access ethnography of four Quebec courtrooms as the evidence base.

A framework without an implementation is simply a concept, a theory, or a model. It provides the rules and the structure, but it cannot do any real work.
Fragere 2.0 is an evolution of this framework into an automated engineering pipeline. Basically, it is a digital platform that automates the STAMP/STPA plus Chaos Engineering framework.
Fragere 2.0 provides engineering, safety, and security teams with a unified workspace to visually model control structures and register Unsafe Control Actions (UCAs)

A working group has formed on "how to communicate the value of STPA":

• First outcome: a backbone document
• Now: work on demos, such as presentation-ready examples and video concepts

Main talking points of the document are:

• Focus on the capability STPA can provide, rather than the method itself
• Different stakeholders need different value propositions.

Demonstrate value through concrete examples rather than explaining the process first

• Develop strategies for objection handling