Episode 16 of The Security Podcast of Silicon Valley came out on May 1, 2022, with Jon McLachlan hosting. The guest was Will Butler, then the red team tech lead at Robinhood and a co-founder of Truffle Security, the company behind the open source secret scanner TruffleHog (Podbean, Apple Podcasts, Spotify, Truffle Security, TruffleHog on GitHub). The episode is called “Will Butler, Red Team at Robinhood and Co-Founder of TruffleSecurity, From Hacking Airports to Leading Red Teams.”
Two threads run through the talk. One is what a red team finds: the gap between how a system is described and how it runs. The other is what happens next, and why Will wants red teams close enough to the rest of security to get the fixes shipped.
This page follows the conversation in order: a section for each part of it, eighteen figures, eight clips from the tape, two videos from Truffle Security, the full transcript, and five tools: a quiz, a scorecard for red team follow-through, a calculator for hosts a rollout missed, a timeline, and a to-do list. Where the decodes of the tape disagree on a word, the transcript puts its best guess in brackets, and the page doesn’t quote or retell those words.
From consulting to Robinhood
Jon opened with the path. Will started as a red team consultant at PwC, working for companies of every industry and maturity. At Apple, Will was on the AppSec team for service products such as Apple Music, iCloud, Apple Pay and Siri. Jon had been at Apple too, and the two compared notes.
Next came management. Will started the red team at Cruise, the self-driving car company in San Francisco, and grew it from zero to eight people.
Then back to hands-on work, as a staff red teamer at BitMEX, a small company facing real stakes and real adversaries. At the time of the episode, Will was the red team tech lead at Robinhood: designing assessments, presenting the results, and using them to shape the security roadmap.
Wikipedia describes Cruise as a General Motors subsidiary that worked on driverless taxis, until GM stopped funding it in December 2024 (Wikipedia). BitMEX is a cryptocurrency exchange and derivatives trading platform, founded in 2014 (Wikipedia). Robinhood is an electronic trading platform based in Menlo Park, which listed on Nasdaq on July 29, 2021 (Wikipedia).
Jon also introduced Will as a co-founder of Truffle Security, which builds an enterprise product around TruffleHog. Truffle Security’s chief executive, Dylan Ayrey, was the guest on episode 9 (Truffle Security). Will named two more co-founders, Dustin Decker and Julian Dunning.
The airport session cookie
The story Will likes to tell starts with a summer job at a local airport. It turned into an internship in the airport’s IT department. While chasing a bug for a coworker, Will found a web application on the network.
“And I noticed that it was returning a very suspiciously small session ID cookie.”
Will Butler, at 4:59
The session ID was a number. After logging out and back in, it had gone up by five. A short script tried thousands of session IDs and landed on an administrator session. Wikipedia calls this session hijacking: using a valid session to get unauthorized access to a system (Wikipedia).
“It turns out that it controlled almost all physical security at the airport, everything from the hand readers to the door locks to the cameras.”
Will Butler, at 5:37
An independent contractor wrote the software. It ran at many airports across the country, and it faced the internet for maintenance. The report went up to the head of the local port authority, and the Secret Service, already at the airport for a security assessment, heard about it.
“getting it patched, and they hired me to review some of their software after that.”
Will Butler, at 6:28
That review was the start of Will’s consulting work.
Three lenses on security
Will reads security through economics, finance and philosophy. On philosophy, Will quoted a line from someone else:
“philosophy is the science of thinking clearly”
Will Butler, at 8:04
Will credits it with more rigor. Jon added a moral angle.
“And I suppose being a red team expert, it changes your relationship to power, right?”
Jon McLachlan, at 8:23
Economics shows what drives attackers. Finance shows the business impact of a vulnerability. Jon carried the point on: a finding can feel scary from a security point of view and still not touch the core business, so the question is whether reaching 100% is worth the cost, or the risk is one to accept. Will added that attackers face incentives too, and Jon agreed that some of them make the same economic choices as businesses.
Attackers who work like dev teams
Will likes reading leaked chat logs from threat actors. Many groups run like an average developer team, with site reliability engineers, software engineers and product managers. A security podcast Will listens to makes the same point. Jon had pictured a faceless adversary.
“They’re human beings, just like the rest of us.”
Jon McLachlan, at 10:39
The division of labor also makes attribution hard.
“One crew might be like the malware developer for several other crews that actually run a campaign.”
Will Butler, at 10:52
Another crew might get initial access and hand it to a different crew that uses it.
Findings that break workflows
Will’s best days are when a red team changes an organization. Many readouts go nowhere, because the findings are inconvenient.
“We tend to find vulnerabilities at the boundaries between different systems and abstractions, and things that are fundamentally insecure by design.”
Will Butler, at 12:07
A finding like that can’t be handed over as a configuration change, a patch or an output encoding fix. The example Will gave was a CI system that is insecure by design, where the fix breaks many other teams’ workflows. Sometimes an assessment starts a large tiger team, a group of specialists put together to solve one problem (Wikipedia), and the breaking changes ship. Core infrastructure changes, the attack surface shrinks, and people are happy with it. Those are Will’s best days.
A crawler that ran attacker JavaScript
The other kind of best day is a good bug, and Will told the story of a favorite. It started before an engagement, while the team registered phishing domains for a client.
“And I noticed that approximately every hour on the hour after we registered these domains, we would get a very specific set of HTTP requests from some odd user agents.”
Will Butler, at 14:29
The requests came from way outdated Chrome and an outdated Python requests user agent. The client ran software that compared new domains with the company’s own domains and pages, to catch lookalikes early. Wikipedia calls this kind of lookalike domain typosquatting (Wikipedia). Will liked the tool, and saw a way in: anything that renders attacker-controlled JavaScript is attack surface.
The software loaded each page in a headless browser, a browser with no graphical interface that renders HTML and runs JavaScript (Wikipedia). The team sent back a payload that used the WebRTC API to read the local IP addresses of the machine running it. WebRTC gives browsers real-time communication, and Wikipedia notes that its IP address leak comes from the way it works (Wikipedia). More JavaScript took screenshots of the web services on that local /24 network.
From a dashboard to every laptop
One of the screenshots showed a dashboard, a vendor product that displayed statistics from a database. Its URL’s query string was the name of the table, and the product evaluated that string as code in an esoteric programming language.
“It’s literally an RCE that’s triggerable from a simple GET request.”
Will Butler, at 16:52
The JavaScript in the headless browser could trigger it. The host it reached was a letdown: little network access, no route to the AWS metadata API, and a read replica of a non-production database with nothing of interest in it.
Then Will looked at how the product handled async results. A database client could name a stored procedure for the server to call on the client when the results were ready. A sandbox was supposed to stop arbitrary code. Will found a way out of the sandbox, and every engineer working on the database was connected to that test database.
“So I was able to exploit their laptops with this sandbox breakout.”
Will Butler, at 18:26
A few iterations later, most hosts in the client’s network were compromised. Jon compared it to tugging on a loose thread at the end of a sweater until the whole thing unravels.
It took a few days. The team was already working with the client’s security team by then, so it asked what the product was and skipped the fingerprinting.
More art than science
Jon sees red teaming as more art than science: intuitions, and a flicker at the edge of vision that a normal engineer writes off as an edge case.
“almost more of an art than a science”
Jon McLachlan, at 19:37
Will reached for Paul Graham’s essay Hackers and Painters, from May 2003, which, as Will put it, says hackers are more like painters than engineers. In the essay, “What hackers and painters have in common is that they’re both makers” (Paul Graham). It also gave its title to a 2004 essay collection (Wikipedia).
“But I actually think a lot of his arguments can extend to offensive security engineers.”
Will Butler, at 20:16
There’s a lot of creativity in the work, Will said, and little formal reasoning about exploits and lateral movement. Jon called that a strength. Red teamers don’t bring preconceptions, so they find out how a system works for themselves.
“you are actually looking at the real bits and pieces that are not what they should be, but what they are.”
Jon McLachlan, at 20:43
A tether to reality
Will picked up Jon’s point. Security and engineering teams often describe their systems the way they should be, the way the documentation says, or the way someone told them. Few of them have operated those systems.
“And so there’s a lot of like little subtle differences between what the documentation says or what somebody tells you and what’s actually going on.”
Will Butler, at 21:26
A red team brings back that ground truth. The story: over beers, Will walked a head of infrastructure through an idea for an attack chain. Two thirds of the way in, the head of infrastructure stopped it. The chain needed SSH into a box, the boxes used an SSH certificate authority, and a certificate required a second factor that the attacker wouldn’t have at that point.
“But like any diligent red teamer, I’m going to try anyway.”
Will Butler, at 22:23
It worked.
“And it’s not because he was wrong.”
Will Butler, at 22:31
SSH CA ran on most systems. The team didn’t know about some systems, so SSH CA never reached them, and they still took passwords and keys. On others it broke some automation, got rolled back, and never came back. A third set took SSH CA certificates and other forms of SSH authentication too.
“I would call that operational rigor.”
Jon McLachlan, at 23:16
Will agreed: exceptions like these are what get a company breached.
The calculator below counts the hosts a rollout like that leaves open.
When the red team breaks something
A worst day, for Will, is causing a production issue.
“So red teams inherently have to do some risky things.”
Will Butler, at 24:06
Red teams change systems they don’t understand as well as they should, and some of those systems serve production traffic. Process and tooling cut the risk, and once in a while something slips through. Will’s teams have kept outages contained, because an internal red team works closely with the other engineering teams.
The favorite bug had a cost. The database’s runtime was single-threaded and synchronous by default. Will’s script to list and exploit the connected clients ran synchronously, so nothing else on the system could make progress while it ran. It was a test system, so no production traffic was lost. By Will’s own account, few red teamers are as cautious, and the team works to understand a system before acting on it.
Jon noted that a denial of service is too easy to call a red team success. Some systems Will has worked on were fragile, under heavy load or in odd configurations. So the team limits the risk.
“Even if that means, by the way, taking another path.”
Will Butler, at 26:53
Will has had teams drop a promising exploit or lateral movement opportunity and backtrack, because it was too risky.
How the team runs an engagement
Jon asked how the team splits the work. Will’s way: meet, list the research tasks, such as the initial recon, and split them up. When the team is ready to act on what it found, everyone meets on Zoom or in a conference room.
“we actually get together and do that stuff live together.”
Will Butler, at 28:05
Then the research splits up again, and the loop repeats until the objective is done.
Operators pair up when research overlaps or needs someone’s expertise. During the independent stretches, updates go to Slack, and each operator works on vulnerability research or recon. Jon heard good feedback loops in that.
Inside or outside
Jon turned to internal red teams and external ones, also called contracted pen testers. A penetration test is an authorized simulated cyberattack on a system (Wikipedia). Will sees people manage one kind as if it were the other and end up disappointed.
An external red team is closer to the real adversary, and it faces the same constraints an attacker does.
“They have a time box.”
Will Butler, at 30:40
It knows little about the company’s security, its controls, its projects or its technology, and has to work all of it out. An internal red team will notice things anyway. Will wants it integrated with the rest of security, knowing what detection and response can do and where the common vulnerabilities are.
“Now, a disadvantage of being so closely integrated is you are biased.”
Will Butler, at 31:41
An internal team can share everyone’s blind spots. In return it can drive change, because it knows each team’s constraints and earns their trust in the aftermath of an assessment. It can help detection and response improve their processes, help the SRE team redesign what it broke, and patch the bug it found.
“You can help patch a bug that you found.”
Will Butler, at 32:23
Jon pointed out that every fix makes the red team’s next attempt harder.
Red teams as product managers
How independent should an internal red team be? Will’s answer comes from experience.
“Personally, I’ve had the greatest success when my internal red teams were not independent at all.”
Will Butler, at 32:41
Integration lets a red team act almost like a security product manager. In a product organization, product managers decide what to build and engineering decides how. In security, InfraSec, AppSec and detection platform teams know how to build: log ingestion pipelines that scale, fixes across a code base, infrastructure that is secure by default.
“But they might not necessarily be the ones who know the most about what security controls, if in place, would make a real attacker’s life most miserable.”
Will Butler, at 33:39
Red teams, and threat intel teams, are the ones qualified to say that.
A report for the buyer
Jon added a use for external reports. A company can ask, or pay, for a customer-facing summary: an initial assessment, a few engineering cycles to fix the criticals and highs, then a second assessment that shows the delta. In a B2B deal, the buyer’s security team asks the hard questions.
“Do you have any internal pen test reports that you can share with us?”
Jon McLachlan, at 35:08
Handing over those reports, Jon said, breaks down sales barriers in B2B deals.
One report, or a patch
Reports mark another difference. An internal team can add value after an assessment in many ways: submit a patch, write the detection rule it wished existed, or join an architecture meeting.
“An external red team usually only has one, which is the report.”
Will Butler, at 35:30
Will learned the other side of this at Apple, reading consultants’ reports on the AppSec team.
“I never understood how useless my own recommendations were as a consultant until I started being on an internal security team.”
Will Butler, at 35:58
Consultants don’t have the internal context, so their recommendations come out generic. In Will’s first days at Apple, the team heard Will’s standard consulting answer and listed 16 edge cases, limitations and restrictions that ruled it out.
“Now help us.”
Will Butler, at 36:57
Will had to learn those restrictions and design a fix that mitigated enough. Internal teams find more, with the advantage of knowing the stack and the people. Their reports are lighter, because the findings go into tickets, meetings and pull requests.
“So I actually find the external team’s reports tend to be of significantly higher quality.”
Will Butler, at 38:31
Jon’s take: the report is an external team’s only channel, and its name goes on it.
Experts you can’t hire
External firms can hire subject matter experts that a single company can’t justify, such as a full-time cryptocurrency expert.
“But Trail of Bits does.”
Will Butler, at 39:10
Trail of Bits can sell that expert’s time to every client who needs it. An internal red team is made of generalists. So Will likes both on the same system. The external team is less biased and brings deeper specialists, and the internal team brings context.
At one company, Will’s team and an external red team ran an assessment together.
When should a startup start?
Jon asked when a startup, especially in a regulated space, should get its first assessment. Will expects few early startups to hire a red team, and still sees value in starting early.
“hiring a red team early, even if it’s just a single person”
Will Butler, at 40:53
Even someone with the background who doesn’t red team full time can bring the product management view and the ground truth, and help design the first infrastructure. Will expects that to pay off for years. Red teams usually get invited in after infrastructure has so much momentum that it’s hard to change.
An interview question with no floor
Will’s favorite interview question for an offensive security role is a hypothetical. The first assignment is to recover one file worth a lot, with no access and no inside knowledge.
“some like individual file of immense value.”
Will Butler, at 42:22
The candidate starts with recon: IP space, domains and subdomains, where they point, which cloud, whether there are S3 buckets. Will supplies assumptions to narrow it down, such as what the recon or a port scan returned. Then Will drills into each topic the candidate raises until someone’s knowledge runs out, the candidate’s or Will’s.
“because the candidate is almost entirely in control of the technical topics that we discuss.”
Will Butler, at 44:18
The example was command injection.
“explain to me a command injection vulnerability as if I’m the developer who wrote it.”
Will Butler, at 44:39
The follow-ups go deeper: the root cause, the fix, finding it across many applications, debugging error conditions, exploiting it blind, and getting results out when egress is locked down. Wikipedia covers command injection under code injection, where a program treats external input as executable commands (Wikipedia).
“What if egress was heavily restricted?”
Will Butler, at 45:10
Jon heard the creativity from earlier in it: a depth-first search into small glimmers of odd behavior in software written by people who mean well.
Insight under pressure
That reminded Jon of a book, Gary Klein’s Seeing What Others Don’t: The Remarkable Ways We Gain Insights, from 2013. Klein is a research psychologist who studies how experts, such as firefighters, decide under time pressure, and Wikipedia credits him with a multi-path model of insight (Wikipedia). Jon described two of the paths.
“One of them is noticing a contradiction.”
Jon McLachlan, at 47:44
The other is creativity under constraint, and time is often the constraint. Jon told the story of firefighters on a hillside, with the wind turned against them and a wildfire they couldn’t outrun.
“And the best way to protect themselves from this raging fire was to actually start a fire.”
Jon McLachlan, at 49:00
Ground that has already burned can’t burn again. Wikipedia’s article on the Mann Gulch fire, in Montana in 1949, describes the same move: the foreman lit an escape fire and lay face down in the burned area while the main fire passed (Wikipedia). Jon tied it to red team work: a time box and the limits of the system push people toward creative answers.
The binary you can’t fix
Will has a second interview question that flips to the defender’s side. A vendor ships an executable known to be insecure. The business needs it, and it has to accept input from across the internet.
“You can’t reverse it or change it for legal reasons.”
Will Butler, at 50:23
So how do you run it as securely as possible? Will asks because, in Will’s view, most security people focus on the vulnerabilities and less on the other layers of defense.
Constraints also shaped Will’s time at BitMEX: a small team, high stakes and real adversaries.
“Go to a place with high stakes, constraints, and real adversaries, and you will be forced to learn a lot.”
Will Butler, at 51:28
Jon added that growth happens outside your comfort zone, one of the best reasons to join or start a startup.
The engagement ends at the goal
Jon asked for parting words, and Will gave two. The first was red teams as product managers.
“First word of wisdom is red teams can make really interesting PMs.”
Will Butler, at 52:10
The second was about layers. Between an attacker exploiting a vulnerability and reaching a goal, a defender can put many layers of defense in the way, and each one is a chance to make attackers miserable. Wikipedia calls the idea defense in depth (Wikipedia).
“The engagement doesn’t end with the vulnerability. It ends when they accomplish their goal.”
Will Butler, at 52:47
“I think a lot of people tend to over-index on vulnerabilities specifically.”
Will Butler, at 52:58
Becoming a red teamer
Jon’s last question: what should someone do to get into red teaming? Will’s answer starts with breadth. Red teamers have to be generalists. A specialty is fine, but the list is long: social engineering and phishing, how the internet works, how modern software is built, several programming languages, finding and exploiting application security bugs, how IT organizations work, and how software gets onto a laptop.
“You should really thoroughly understand the defender.”
Will Butler, at 54:01
That means the defender’s monitoring tools, the footprint your activity leaves in them, and the person reading the alerts.
“Understand that there’s a human sitting behind that screen, looking through thousands of alerts”
Will Butler, at 54:12
Will’s advice is to work on different kinds of security teams, such as detection and response, secure infrastructure and application development, and to build things and break them.
Contributing to open source helps too. Find security tools that interest you, learn how they work, fix bugs and add the features you’ve wanted. Jon and Will both pointed listeners to TruffleHog, which is open source (GitHub).
What happened after the tape
A Series B for Truffle Security. On November 6, 2025, Truffle Security announced a $25 million Series B led by Intel Capital and a16z. The release counted more than 23,000 GitHub stars for TruffleHog, 15 million downloads and more than 250,000 runs a day (Truffle Security). The Series A, $14 million led by a16z, came on December 8, 2021 (Truffle Security).
Revoking leaked secrets for free. On November 4, 2026, Truffle Security launched a free Secrets Revocation Program for companies that issue credentials, starting with 1.4 million verified, live credentials found in public code and packages. In a 2025 study, 81% of 21,981 live keys reported to their owners and issuers still worked six months later (Truffle Security). Reporting alone didn’t close the gap, which is the point of One report, or a patch.
Two videos from Truffle Security. Four weeks before this episode, Truffle Security posted an introduction to TruffleHog v3, “an open source secrets detection engine.” The day after the episode, it posted a NahamCon 2022 talk on how red teams and state-sponsored attackers get into companies. Truffle Security made both videos.
More is on Truffle Security’s YouTube channel, LinkedIn page and X account.
Cruise wound down. Cruise suspended operations in October 2023 after a series of incidents, and GM stopped funding it in December 2024, moving the work into driver assistance for personal cars (Wikipedia).
Truffle Security on this show. Dylan Ayrey was the guest on episode 9, on how open source makes the world more secure. On episode 84, Jack Cable of Corridor named Dylan among the angel investors in Corridor’s first round.
Did you catch it? A seven-question quiz
Seven questions from the episode. Each answer links the moment in the transcript or its section.
Quiz · seven questions
Did you catch it?
Pick an answer to see whether you caught it.
-
What gave away the administrator session in the airport's security system?
a. "And I noticed that it was returning a very suspiciously small session ID cookie." Transcript, 4:59.
-
Where do the findings that stall tend to sit, in Will's experience?
c. "We tend to find vulnerabilities at the boundaries between different systems and abstractions, and things that are fundamentally insecure by design." Transcript, 12:07.
-
Why was the client's lookalike-domain checker attack surface?
b. The checker ran the red team's JavaScript in a headless browser. See A crawler that ran attacker JavaScript.
-
Why did the attack chain work, even with SSH CA in place?
a. SSH CA ran on most systems, and the exceptions were enough. See A tether to reality.
-
What's the main drawback of an internal red team that works closely with the rest of security?
b. "Now, a disadvantage of being so closely integrated is you are biased." Transcript, 31:41.
-
What can a red team tell security engineering that the builders may not know?
c. "But they might not necessarily be the ones who know the most about what security controls, if in place, would make a real attacker's life most miserable." Transcript, 33:39.
-
When does an engagement end, in Will's words?
b. "The engagement doesn't end with the vulnerability. It ends when they accomplish their goal." Transcript, 52:47.
Do your red team’s findings get fixed?
Eight questions on whether your testing turns into fixes, built from the episode. Each tip links the section behind it.
Scorecard · eight questions
Do your red team's findings get fixed?
Answer for the systems you'd least like an attacker to reach, whoever tests them today. If two answers fit, pick the lower one.
-
What happens to findings after an assessment?
- A report, and little changes
- Tickets for the easy fixes
- The testers help ship the fixes: patches, detection rules, design reviews
"An external red team usually only has one, which is the report." See One report, or a patch.
-
When a finding is insecure by design and the fix breaks other teams' workflows, what happens?
- It waits
- It has an owner but no date
- A tiger team ships the breaking change
"We tend to find vulnerabilities at the boundaries between different systems and abstractions, and things that are fundamentally insecure by design." See Findings that break workflows.
-
Does anyone test that a control runs everywhere the documentation says?
- We trust the documentation
- Spot checks now and then
- Someone hunts the exceptions: unknown hosts, rollbacks, fallback logins
"And it's not because he was wrong." See A tether to reality.
-
How closely does your red team work with detection and response?
- Separately, with results at the end
- They share readouts
- The red team knows what they can detect and helps them improve
"But the advantage is that it's much easier for you to influence change" See Inside or outside.
-
Who decides which security controls to build next?
- Whoever builds them
- The next audit
- The red team and threat intel weigh in on what would hurt attackers most
"Personally, I've had the greatest success when my internal red teams were not independent at all." See Red teams as product managers.
-
If an attacker exploits one vulnerability, what stands between it and your most sensitive data?
- Not much
- One or two controls
- Several layers, each one tested
"The engagement doesn't end with the vulnerability. It ends when they accomplish their goal." See The engagement ends at the goal.
-
When did an outside team last test the same systems?
- Never
- More than a year ago
- In the last year, with the specialists the system needs
"But Trail of Bits does." See Experts you can't hire.
-
Does your red team have rules for production risk?
- No
- Informal ones
- Written limits, and a habit of backing off risky paths
"Even if that means, by the way, taking another path." See When the red team breaks something.
The testing happens, and little changes. Bring the testers into tickets, pull requests and design reviews, and give the hardest finding an owner and a date.
The quick findings get fixed. Next, hunt the exceptions to the controls you count on, and staff a tiger team for the finding that breaks workflows.
Keep an outside test on the calendar for fresh eyes, and keep adding layers between a bug and your most sensitive data.
How many hosts did the rollout miss?
The calculator counts the hosts outside a control like SSH CA, using the three groups from A tether to reality.
Calculator
How many hosts did the rollout miss?
Five numbers: the hosts in your fleet, the share the team doesn't know about, the share where the rollout was rolled back, the share that still takes other logins, and how many hosts an attacker can reach.
In a fleet of 1,000 hosts, 10% sit outside the rollout: about 100 hosts that still take a password or key. An attacker who reaches 10 hosts at random has a 65% chance of landing on at least one.
The three groups come from the tape. The percentages are placeholders. The math assumes the groups don't overlap and that the attacker reaches hosts at random. In Will's story, the exceptions were enough to keep the attack chain going.
From an airport to TruffleHog
The companies on Will’s path, Truffle Security, the field around them, and this show. Filter by topic.
Timeline
From an airport to TruffleHog
- Mann Gulch
A wildfire in Montana, where the foreman survives by lighting an escape fire (Wikipedia, on this page).
- Tiger teams
A paper on program management uses the term for a team of specialists sent after every possible failure (Wikipedia).
- Hackers and Painters
Paul Graham's essay on hackers as makers (Paul Graham, on this page).
- The essay collection
Hackers & Painters comes out from O'Reilly Media (Wikipedia).
- Cruise
The self-driving car company is founded (Wikipedia).
- Robinhood
The trading platform is founded (Wikipedia).
- Seeing What Others Don't
Gary Klein's book on how people gain insights (Wikipedia, on this page).
- BitMEX
The cryptocurrency derivatives exchange is founded (Wikipedia).
- The WebRTC leak
TorrentFreak reports that WebRTC can expose a user's real IP address (Wikipedia, on this page).
- GM buys Cruise
Cruise becomes a General Motors subsidiary (Wikipedia).
- Robinhood goes public
Robinhood lists on Nasdaq as HOOD (Wikipedia).
- Episode 9
Dylan Ayrey of Truffle Security on open source (episode 9).
- Series A
$14 million, led by a16z (Truffle Security).
- TruffleHog v3
Truffle Security posts an introduction to the new version (YouTube, on this page).
- This episode
Will on the show (Podbean).
- No Malware Needed
Truffle Security posts a NahamCon 2022 talk on how red teams get into companies (YouTube).
- Cruise pauses
Cruise suspends operations after a series of incidents (Wikipedia).
- GM stops funding Cruise
The work moves into driver assistance for personal cars (Wikipedia).
- Series B
$25 million, led by Intel Capital and a16z (Truffle Security).
- Secrets Revocation Program
A free program to revoke leaked credentials, starting with 1.4 million live ones (Truffle Security, on this page).
What to do this week
Five things, in the order of the episode.
- Hunt the exceptions to your controls. Pick one control you count on, such as SSH certificates or single sign-on, and look for the hosts that skip it: unknown systems, rollbacks and fallback logins, as in A tether to reality. The calculator shows how fast a few percent adds up.
- Give the hard finding an owner. For a finding that is insecure by design, put a small tiger team on it with a date, as in Findings that break workflows.
- Bring the red team into the fixes. Invite it to tickets, pull requests and design reviews, and ask which controls would hurt an attacker most, as in Red teams as product managers. The scorecard shows where to start.
- Scan for leaked secrets. Run an open source scanner such as TruffleHog over your code and its history.
- Get help with it. Our Penetration Testing team tests the way an attacker would, Product Security helps get the fixes into the code, and a vCISO can own the program. If you want to talk it through, book 15 minutes with us.