{"slug": "find-the-vulnerability-hiding-between-the-features", "title": "Find the Vulnerability Hiding Between the Features", "summary": "Yurii B. has proposed Security Scenario Explorer, a security-testing workbench built on the Combinatorics Framework JVM that targets interaction-driven vulnerabilities arising from combinations of context, state, action order, and exceptional events. The framework plans experiments before execution, reports candidate counts, supports budgeted t-way selection via a greedy strategy, and triages failures down to small reproducers, with intended coverage of authorization and tenant isolation, session lifecycle, business-logic abuse, configuration interactions, and AI-agent boundaries. It is positioned as complementary to scanners, DAST, and fuzzers rather than a replacement.", "body_md": "*Security Scenario Explorer — a proposed security-testing direction built on Combinatorics Framework JVM.*\n\nMost security tools look for known weaknesses. But some vulnerabilities appear when individually valid requests interact in an unexpected order.\n\nA permission changes while a session remains active. A retry arrives after a timeout. A webhook is delivered twice. An AI agent reads untrusted content while holding access to a privileged tool. Each operation may look legitimate in isolation; the sequence may still violate a security boundary.\n\n**Security Scenario Explorer** is a proposed workbench for investigating these interaction-driven failures systematically. It builds on Combinatorics Framework JVM, a scenario-modeling and execution framework developed by Yurii B.\n\nIt is not positioned as a replacement for vulnerability scanners, DAST, or fuzzers. Its intended focus is security behavior that depends on combinations of context, state, action order, and exceptional events, therefore - reassures you even more in considered direction of potential risks.\n\nBroken access control remains the top category in the [OWASP Top 10:2025](https://top10.owasp.org/2025/), which also includes security misconfiguration, authentication failures, insecure design, and mishandling of exceptional conditions. The [OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) highlights broken object-level authorization. For AI applications, the [OWASP Top 10 for LLM Applications:2025](https://genai.owasp.org/llm-top-10/) includes prompt injection and excessive agency.\n\nThese risks often require more than a single request to investigate. The relevant question is not only “Does this endpoint reject a bad input?” but also “Does the system preserve its security rules after this sequence of valid actions and unexpected events?”\n\nInstead of starting only from a list of known vulnerability patterns, describe what can vary, what must remain true, and how much execution is acceptable:\n\nThe framework plans the experiment before execution, reports candidate counts, and supports budgeted *t*-way selection using a greedy strategy; it does not claim to find a mathematically minimal test set. Candidates run through configured adapters. Verdicts distinguish application failures from harness or infrastructure problems, and failure triage can reduce a failing case to a small reproducer for verification and regression testing.\n\n**Authorization and tenant isolation.** Can a user access another tenant’s resource after a role change, or does a stale session retain a capability that should have been revoked?\n\n**Authentication and session lifecycle.** What happens when credentials expire or are revoked in the middle of a workflow?\n\n**Business-logic abuse.** Can retries, replays, duplicate transactions, or unusual action ordering violate a financial or data-access invariant?\n\n**Configuration interactions.** Can a combination of settings or feature flags make a restricted operation reachable?\n\n**AI-agent boundaries.** Can untrusted content influence an agent to use a tool beyond its granted permissions or bypass an approval requirement?\n\nAn AI assistant can help formulate threat hypotheses, build scenario models, interpret results, and suggest follow-up experiments. The human remains responsible for the authorized scope, the security properties being tested, and approval of consequential actions.\n\nA finding should not be accepted because a tool or model calls it a vulnerability. It should be supported by a clearly stated invariant, an observed violation, and a reproducible test. Before trusting a security oracle, calibrate it with a known test defect and confirm that the test can detect the failure it is supposed to detect.\n\nThe underlying Combinatorics Framework JVM already supports context, sequence, and event modeling; constraints; plan and candidate counts; budgeted candidate selection; execution through configured adapters; verdict classification; failure-witness triage; checkpoints; and an AI-operator workflow with approval gates.\n\n**The security-specific layer is still planned, not demonstrated.** That includes reusable security oracles, a scope guard, operating-system-level isolation, a concurrent-dispatch adapter, and ready-made scenario packs beginning with API authorization. Defined event injection covers chosen points in a sequence; it does not by itself test two requests arriving at precisely the same time.\n\nThere is also an important safety limitation today: generated Java runs inside the JVM without an operating-system sandbox. A security edition needs explicit scope declarations and target allow-lists, execution limits, timeouts, secret redaction, auditable run records, and isolation for generated code before it can be presented as safe for broader security-testing use.\n\nThe first milestone should be a reproducible authorization or business-logic flaw that a single-request test misses. Publish the scenario, the invariant it violates, the observed result, and a minimal reproducer - then rerun it as a regression test.\n\nThe goal is not to claim that every attack can be enumerated. It is to make a defined security investigation more systematic, bounded, repeatable, and re-viewable.\n\n**Model what must remain secure. Explore the interactions that could break it. Preserve the evidence.**\n\nSecurity Scenario Explorer is a proposed direction, built on [Combinatorics Framework JVM](https://github.com/ghYura/Combinatorics-Framework-JVM). If you work in AppSec, penetration testing, or security-minded QA, share a real cross-feature failure pattern that would benefit from a reproducible scenario model.\n\n*Combinatorics Framework - re-assuring safety behavior more, saving QA jobs as a test-space scenario designer-architect/supervising AI*", "url": "https://wpnews.pro/news/find-the-vulnerability-hiding-between-the-features", "canonical_source": "https://dev.to/yb_combi/find-the-vulnerability-hiding-between-the-features-23jk", "published_at": "2026-10-28 05:30:56+00:00", "updated_at": "2026-10-28 05:41:33.838055+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "developer-tools", "ai-tools"], "entities": ["Yurii B.", "Combinatorics Framework JVM", "Security Scenario Explorer", "OWASP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/find-the-vulnerability-hiding-between-the-features", "markdown": "https://wpnews.pro/news/find-the-vulnerability-hiding-between-the-features.md", "text": "https://wpnews.pro/news/find-the-vulnerability-hiding-between-the-features.txt", "jsonld": "https://wpnews.pro/news/find-the-vulnerability-hiding-between-the-features.jsonld"}}