I Reviewed 180 fwd:cloudsec Submissions, These Are My Key Takeaways

We recently finished reviewing all the proposals for fwd:cloudsec North America 2024. This year saw over 180 submissions, and a very high bar indeed was set. There were several common themes in reasons why I scored a submission the way I did. I reckon other reviewers were scoring similarly, given the discussions I took part in. I thought I’d share some of my observations here. This is all particularly relevant to fwd:cloudsec EU, given I’m leading the CfP there. That said, I’m sure a lot of it will generalise to other cybersecurity cons too.

The Positives

Many submissions were a delight, and made it simple for the committee to select them for the final slate. Most of the talks that were easy acceptance decisions ticked some, if not most, of the following boxes:

A well thought out and detailed submission that makes it clear what they wanted to talk about
Had clearly read and absorbed the CfP guidelines on the conference website
Allowed the committee to assess the speaker’s credibility for the submitted topic. Reviews were initially done blind, so we based this on the submission detail, not who the speaker was.
An explanation of why their content would be useful and relevant to our attendees
Novel content, and an explanation of how their work fit into prior art and the broader industry
A demonstration that they were talking from real world experience
Detail on how they’d spend the time, especially if they’d requested one of the longer session types

What Counted Against a Submission

There were similarities among submissions we turned down, too. I’ve included the most common and important ones below.

Low Effort/No Detail

It was depressingly common to see people submit a few very high level lines of text in the abstract, without any further explanatory notes. We get it, everyone’s a busy professional with a lot going on, and writing a submission up in depth takes a lot of time. However, as a reviewer, this leaves me with three concerns:

There’s not enough detail for me to understand what you want to talk about, and whether that’s a good fit for the event.
I don’t know if the content will be at a level that is appropriate for our audience, or whether they’ll find it interesting.
If you’ve not taken the time and effort to put a solid, descriptive submission together, can we trust that you’ll bring a high quality talk to the conference?

You want to make it as easy as possible for reviewers to accept your talk, and it makes our lives as reviewers easier if we’ve got plenty of detail to work with. Generally speaking, the more detail you can provide, the better!

It’s also important to note that you shouldn’t rely on your reputation to get your submission accepted, either. I’ve seen very lightweight submissions get accepted at some conferences largely on the strength of the speaker’s repuation. It works at some events, but many of the better conferences (fwd:cloudsec included) do at least one round of reviews “blind”, with the speakers’ names hidden. This helps to reduce reviewer bias, and has been shown to help diversify the speaker pool and lower the bar for newer speakers. Even without that, it’s possible some reviewers may not know who you are, even if you headline Black Hat on a regular basis. As such, the best submissions stand tall entirely on their own merits, without factoring in the speaker.

Smells Like a Sales Pitch

Many organisations have a vested financial interest in their staff speaking at events. This is often for brand building and showing off what they’re capable of to potential buyers. This is fine, and well understood by reviewers. What no one wants to see, at a practitioner-focused event, is a sales pitch. What do I mean by a sales pitch? If you’re talking about organisations solving a problem by paying for your company’s offerings, it’s a sales pitch.

Most submitters are honest, and are here to show off interesting work and cool research. Sadly, a few people ruin it for everyone else, and try to sneak a disguised product sales session in. As a result, reviewers usually scrutinise submission for indications that a vendor might be trying to pitch their products. It’s easy for talks to get caught in the crossfire here, unfortunately. I’ve seen well-intentioned submissions (including my own!) get rejected for this reason. Reviewers often reject talks they think might be a sales pitch, just to be on the safe side. The following might help you avoid being misinterpreted:

If you’re talking about tools you want to show off, make it clear that they’re free/OSS
Be very clear to differentiate your products and services from what you’re submitting. If your company focuses on the space you’re presenting on, you should acknowledge that. You should then make it clear how this submission won’t be a sales pitch for their products. You could explain how the submission is going to be product-agnostic, or how it’ll discuss a range of different approaches.
Avoid mentioning the company name all over the submission. The company name is relevant if you want to present how you solved a particular challenge. As a vendor, mentioning it can make the submission sound more vendor pitch-y.

No New Content

At high-end or specialist conferences, existing content is less desirable than something new. Be clear how this will differ from prior work, if you’ve delivered the talk elsewhere. We also had a few submissions this year that were looking to present the contents of a blog post. If I can go read a blog post covering the submission, I don’t personally see why we’d spend a talk slot to listen to it. I’d rather make space for something new. This isn’t a universally held view, but I’m not the only one who raised this on the committee. Given that, it’s worth explaining how you plan to build or expand on the blog post in situations like that.

Doesn’t Fit the Conference Theme

Many conferences have specific themes or topics they focus on. In the case of fwd:cloudsec, it’s public cloud infrastructure security. Some content will cover related topics too, such as cloud native/Kubernetes, SaaS, cloud-based identity systems and so on. Expect talks to be rejected if you can’t show relevance to their audience. As an example, this year, we saw quite a few appsec-focused submissions. These tended to score very low in the initial reviews, and were quickly ruled out.

Inappropriate for the Audience

Reviewers are looking for content that’s appropriate for the conference’s audience. Entry level content isn’t likely to get accepted at a specialist conference. It’s a waste of the audience’s time, if they’re already experienced. Equally, most of the audience won’t follow niche content at a more generalist con. Target your submissions to events appropriate for what you have to say.

This doesn’t in any way mean that newer speakers or less experienced members of the community should not submit to specialist or higher-end conferences. Some of fwd:cloudsec’s best talks have been given by novice speakers, and we actively encourage new speakers and less experienced practitioners to submit. Anyone who’s spent time in the trenches has run into something that’s unknown to most other people, or had to work something out beyond the established best practices and standards, and that’s the content specialist cons want to see.

Hard to Tell What You’ll Do With The Slot

Reviewers want the accepted talks to provide value to their attendees. To me, that means I’m looking for a few things:

What will the speaker spend the time we’re giving them on?
- Will they focus on the things we think will be interesting? Or is it going to meander through the less interesting portions to get there?
What will attendees learn from this that they can take away with them?
- Talks should be informative and useful to the listeners. This means actionable, real-world outcomes or advice.
- These days, few people want to see some infosec rockstar rock up to just drop vulnerabilities.

I will likely score your submission lower if I can’t see how you’ll spend the time. This is especially true if you’ve asked for a longer talk slot!

Presenting a Tool

The jury’s definitely still out there on this one. There are specific tool tracks (like Black Hat Arsenal) where it’s appropriate to present on a tool. Personally, I have no desire to see a talk of someone presenting a tool and its feature set outside of that. Presenting a problem, approaches to solving it, and then demoing a tool that you’ve built as part of that work? Great. 20 minutes of “here’s a tool, and here’s all the different tricks it can do”? I’d rather go read your README.md. It doesn’t give the audience much to take away, other than the specifics of your tool. That’s not the kind of learning most people will tune into a conference talk for.

In Summary

There are many ways to write a conference submission, and I love the diversity in approaches that we see. That said, if you want to succeed, you should ensure that your submission:

Provides plenty of detail on the following:
- What you want to say and why.
- How it fits into the broader picture.
- Why it would be interesting to the conference’s audience.
Demonstrates your expertise on the subject matter
Shows how you intend to use the time you’re given
Doesn’t sound like a vendor pitch