I’ve seen this a lot in my work where companies hesitate to conduct phishing exercises that are “too convincing” (or, put another way, too realistic) because they fear documenting poor results. Of course that means the exercise and the learning opportunities are much less impactful. I’ll concede it’s a little different with financial institutions because regulators and auditors will usually see the results at some point but I really admire Gitlab’s commitment to transparency.

I try to emphasize to clients that it’s not a test but a phishing exercise akin to a fire drill. You don’t pass or fail a fire drill - you use it assess how prepared you are for a fire. And if you find that you’re totally unprepared, well wouldn’t you prefer to figure that out before anything is actually on fire?

I love the lure, and I respect the GitLab team for making it public, but this is a tough read - it’s putting way too much responsibility on the end-user. For example I’m a huge fan of security teams using email headers to analyze suspicious messages, but I think it’s a step too far to expect a user to ever look at an email header, no? We can hardly get regular end-users to hover over a link; encouraging them to open up email headers to see what service the mail was sent from, or to understand what a “received” message header vs an x-originating-ip means is counter-productive. Headers are hard to understand even for a security analyst, asking HR or Recruitment or Sales to analyze them and understand them feels like the red-team are underestimating how little time everyone has and overestimating how technical most employees are!

I'm intrigued. Why limit the experiment to 50 employees? Why not everyone except the Red Team?