Submissions
Write for Security Artifacts
If you have taken something apart and learned how it works, there is a place for it here. This page says what we publish, what we do not, and what happens after you send it.
What we are looking for
Work with evidence in it. The strongest submissions show the artifact, the query that found it, the thing that turned out to be wrong, and the rule that came out the other end. A tidy narrative where everything worked first time is usually less useful than an honest one where it did not.
- Case studies. An incident you worked, reconstructed from evidence you are free to publish.
- Detection engineering. A Sigma, YARA or Snort rule, with the tuning notes and the false positive budget. Rules without those are hard to trust.
- Reverse engineering and malware analysis. Especially where the interesting part is the method rather than the sample.
- Tooling. A parser, a script or a workflow that saved you a day, with enough context that someone else can use it.
- Corrections and rebuttals. If something published here is wrong, a piece explaining why is welcome and will run.
What we will not publish
- Anything you are not free to share. Client data, employer telemetry, and material under NDA. If you have to ask, the answer is usually no, and asking your legal team is cheaper than finding out later.
- Identifiable victim information. Company names in a breach writeup need to be already public and relevant, not incidental.
- Working exploit code for a vulnerability that has no patch. Detection logic and mechanism explanation, yes. A weapon, no.
- Vendor marketing. If the conclusion is that a product you sell solves the problem, this is not the venue.
- Anything generated wholesale by a language model and presented as your own analysis. We will notice, and so will the readers.
How to send it
Two routes, depending on what you want.
Post it to the community. Sign up, write it up, and submit it through Community. It goes into a moderation queue and appears under your own byline once reviewed. This is the fastest route and the work stays yours.
Pitch it for the main archive. If you think it belongs alongside the research on the front page, send a short outline rather than a finished draft: what you looked at, what you found, and why it matters to someone defending a network. A few paragraphs is plenty. Contact details are on the masthead.
What happens next
You will get a reply. It may take a couple of weeks, because Security Artifacts is one person and reading a technical submission properly takes longer than reading a pitch.
If it runs, expect edits. Mostly structural, occasionally asking you to show your working where a claim is doing a lot of load bearing. Nothing goes out under your name that you have not seen in its final form.
If it does not run, you will be told why. A rejection with no reason is how a contributor decides not to write the next one.
Rights and payment
You keep the copyright in your work. Publishing here grants a non-exclusive right to host it and to include it in the newsletter. You can post it on your own blog, present it at a conference, or take it anywhere else, and we would rather you did.
There is no payment at the moment. Saying so plainly seems better than leaving it unmentioned and letting you find out at the end. If that changes, this page changes with it.
Detection rules and IOC lists that you contribute are published so other defenders can use them. If you would rather they carried a specific licence, say so when you submit and it will be honoured.