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
One route, and it is a form rather than an email address. Sign up, write it up, and submit it through the submission form. It goes into a queue a person reads, and it appears under your own byline once reviewed.
There is no separate pitch step for the main archive and no second inbox to find. A piece that belongs alongside the research on the front page gets moved there from the same queue, with your byline travelling with it. That used to mean sending an outline to an address on the masthead and waiting to be invited to write the thing you had already written, which is a worse deal for you than it sounds and slower for everybody.
Send the finished piece. If it is not right for the archive it can still run in Community, which is a real place with real readers rather than a consolation prize.
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.