Skip to content

Research: contrastive positive/negative C# ownership challenge corpus (micro_service_seclab-inspired) #442

Open

Description

@PhysShell

Classification

Motivation

The Java project is not an analyzer and is not a benchmark for Own.NET ownership semantics. Its useful pattern is to encode the same security-relevant dataflow through several library/API and language shapes and pair vulnerable examples with deceptively similar safe ones. Its documentation discusses a CodeQL SSRF miss along URL → String.valueOf(URL) → Request.Get(...), then shows how a missing flow step changes the result. This is historical teaching material, not evidence that current CodeQL still misses the case.

Translate the testing method, not the Java vulnerabilities: for one already-supported Own.NET lifetime/ownership rule, can a manually reviewed, contrastive collection of C# paths expose frontend, alias/summary, control-flow, or reporting blind spots that ordinary happy-path tests miss? Crucially, a case where a checker emits some warning is not a pass unless the right warning is attached to the right resource/path.

Distinct scope / avoid duplicated work

Bounded pilot

Inventory first. Identify one (maximum two) currently supported, high-value ownership diagnostic families and existing tests/issues. Prefer an established use-after-dispose or missed-Dispose obligation where independently adjudicated oracle cases already exist. If the intended variant needs unsupported semantics or a missing call fact, mark it as such rather than interpreting no warning as a soundness defect.

Create at most 8–12 small compiling C# cases in the existing fixture format, intentionally varying how the same resource/use/release relationship is expressed. Candidate dimensions, only where supported and relevant:

  1. Direct vs alias: dispose one reference, then use the same object through another alias; safe lookalike disposes an unrelated object.
  2. Direct vs call boundary: a known consuming callee versus a demonstrably non-consuming callee, including a receiver/argument distinction; classify missing/unknown summaries separately.
  3. Straight line vs guarded cleanup: using / try/finally / if (disposing) / early return where ownership obligations genuinely differ; do not assume exception paths are equivalent.
  4. Declaration reshaping (optional): partial-class teardown or harmless file/method split that still preserves the relevant obligation; reuse existing fixtures rather than cloning Research: refactoring-aware metamorphic regression testing for ownership analysis (RefactoringMiner prior art) #432.

For each family represented, include independently reviewed positive and close negative cases. Examples must not quietly change resource identity, transfer contract, dynamic dispatch, control-flow feasibility, exception behavior, or diagnostic applicability. Java/SQL/SSRF semantics are only inspiration and must not be presented as Own.NET rules.

Required case metadata and adjudication

Before running the analyzer, record in a compact per-case manifest:

  • stable case ID, source revision, diagnostic family, positive/negative expectation, and why;
  • relevant resource identity, ownership/acquire/transfer/release/use events, expected family and location/range;
  • semantic shape tags and any known precondition/support boundary;
  • build/extraction result, analyzed revision/mode, actual diagnostic family/location, and first suspected divergence if mismatched.

Outcomes must distinguish expected finding, missed expected finding, unexpected warning on reviewed safe case, unsupported/unknown semantics, invalid oracle or compile failure, and infrastructure failure/timeout. Do not score the last three as TP/FN/TN/FP. A different unrelated warning, generic nonzero exit, or a compiler failure is not a detected ownership bug. Don't silently treat an absence of diagnostics as a proof of safety.

Deliverables / acceptance criteria

Stop gate / non-goals

STOP if the proposed cases duplicate #405/#427/#432, independent oracle review is not defensible, applicable rules do not support the scenarios, or the maintenance cost exceeds the incremental coverage. A synthetic fixture cannot establish prevalence in real C# projects or overall analyzer soundness.

Out of scope: porting the Java lab or security rules; adding general SQLi/SSRF/RCE analysis to Own.NET; migrating to a new test framework; a giant benchmark import; automatic issue spam; new production diagnostics/summary semantics by default.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions