Related work at USENIX Security is an adversarial exercise: the committee contains people who wrote the nearest prior papers, and the multi-cycle Big-Four calendar means the nearest prior paper may be four months old. This skill covers coverage, differentiation, and the venue's citation mechanics.
| Lane | Where it lives | The question your text must answer |
|---|---|---|
| Big-Four security | USENIX Security, IEEE S&P, ACM CCS, NDSS | Same problem, same class of technique — what's new here? |
| Specialty security | PETS, SOUPS, RAID, ACSAC, WOOT, DIMVA, ESORICS | Did the niche community already do this at smaller scale? |
| Adjacent systems/ML | OSDI/SOSP, SIGCOMM/IMC, NeurIPS/ICML | Is the "security" contribution a re-badged systems or ML result? |
| Industry/offense track record | Black Hat/DEF CON talks, vendor blogs, CVE history | Do practitioners already know this? (Reviewers here often do) |
| Preprints and the cycle pipeline | arXiv, prior cycles' accepted-paper lists | What landed in the last 6–12 months that you must acknowledge? |
The fourth lane is distinctive: at this venue, an attack "known in the community" via a conference talk or advisory — even without an academic paper — weakens a novelty claim, and reviewers will cite the talk. Search offensive-industry sources, not just DBLP.
With USENIX Security itself, CCS, NDSS, and S&P all running multiple deadlines, the relevant literature refreshes roughly every quarter. Concretely:
Comparison tables of checkmarks read as advertising. The pattern that works here is mechanism-level: state what the prior system assumed or measured, then the delta. Three useful framings:
If the honest delta is "same idea, better engineering," consider whether the
contribution framing should change before the related-work section does (see
usenixsec-topic-selection).
Cite your own prior work in the third person as if written by strangers; the '26 CFP names first-person self-reference as an anonymity violation. When a paper builds so directly on your unpublished or just-published system that third person fails, the mitigation hierarchy is: cite an anonymized tech report in the artifact mirror; failing that, consult the chairs — never silently omit a paper reviewers will know exists, since a missing obvious citation both distorts positioning and fingerprints the authors.
@inproceedings{example-sec24,
author = {Doe, Jane and Roe, Riley},
title = {Sample: What a USENIX Security Reference Looks Like},
booktitle = {33rd USENIX Security Symposium (USENIX Security 24)},
year = {2024},
publisher = {USENIX Association},
url = {https://www.usenix.org/conference/usenixsecurity24/presentation/...}
}
Verify metadata against the usenix.org presentation page or DBLP's conf/uss
stream; both were consistent sources historically (DBLP direct fetch 403'd in this
environment on 2026-07-08 — cross-check via search rendering if needed).
Related work usually closes the body (≈1 page of the 13). Two exceptions worth making: an attack paper whose novelty hinges on a subtle difference from a known technique should differentiate early, in the introduction; SoK-style framing (if pursued at all — check the current CFP for whether the venue solicits it, 待核实) makes the literature the paper's subject rather than its perimeter.
[Coverage] five lanes swept, with dates of the last sweep per lane
[Nearest neighbors] top 3–5 with mechanism-level deltas drafted
[Concurrent] same-window items + acknowledgment wording
[Self-citations] third-person rewrite check: pass / violations listed