EM-TEC-07 · Subject model · W2
Vulnerability, affectedness and remediation
Vulnerability description, affectedness assessment, priority and remediation confirmation. A discovered weakness is not identical to its exploitation.
Partially published; research continues
Claude: complete-frozen-study-plus-one-audit-no-rerun; Grok: complete-exact-prompt-reconciled.
Published results
Research note, in Russian: Canonical/runtime promotion remains governed by the package allocation, identity and dependency holds.
Subject boundary and candidate types
- Vulnerability
- AffectednessAssessment
- Remediation
- ExploitEvidence
Deep research questions
- When is a component version actually affected?
- How to distinguish generic severity from contextual risk?
- How to prove a fix in production?
Verifiable invariants
- CVE is not the only admissible ID
- An assessment specifies a version and a context
- A closed ticket is not proof of remediation
End-to-end acceptance scenario
Verify a component with conditional affectedness, a fixed build and a not yet updated instance.
Negative case
The presence of a CVE in a transitive dependency automatically means a confirmed incident.
Approaches to compare
- AISMM/WM-SFT and ArchiMate: product, system and architecture
- CSDM: business application, service and runtime instance
- SPDX/OpenTelemetry/Google SRE: delivery, observation and reliability; choose by boundary
Candidates in the live catalogue
- WM-SFT-006 · Vulnerability Record · 0.3.0-research.1 · installable
Semantic fit requires boundary research; a published model does not by itself complete this card.
Result requirements
Every card is executed together with the full research contract: definitions, fields and cardinalities, lifecycle, sources, data mastership, rights, the five object facets, at least eight invariants, positive and negative examples, dependencies, migration and applicability limits.