Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:16):
Hello everybody,
Thank you for tuning in to
today's episode of what's New inData.
Super excited about our guesttoday we have Brian Vallalunga,
CEO and founder of Doppler.
He previously was anengineering lead at Uber.
Brian, how are you doing today?
I'm doing great.
Speaker 2 (00:30):
Thanks so much for
having me here, very excited to
be chatting about Seekers today.
Speaker 1 (00:35):
Yeah, absolutely.
It's a great topic.
It's top of mind for everyonewho's bringing great
applications to market butreally need to think about the
security and making sure thatthey're bulletproof in terms of
not allowing inadvertent accessto sensitive data and controls.
But, brian, first tell thelisteners a bit about yourself.
Speaker 2 (00:55):
Yeah, sure, so I'm
the CEO and founder of Doppler.
A little background about whatDoppler is is we help developers
and engineering teams managetheir secrets, and I'll get into
a little bit of what secretsare.
We help companies as small aslike one or two person teams and
startups all the way up tomultiple five companies that are
in the Fortune 500.
So we kind of range across theindustry and helping them manage
(01:18):
their secrets securely, butalso in a way that it fits into
the developer workflow.
So we kind.
So the kind of inspiration forDoppler is to make vegetables
taste like candy, vegetablesbeing security, candy being the
developer productivity.
Speaker 1 (01:32):
Oh, I love that, I
love that.
So what are secrets and why dothey matter?
Speaker 2 (01:36):
Yeah, so I'm on the
show today as a PSA a public
service announcement because,just in general, people,
listeners on this show,engineers, and not all use a set
of services every single day.
So, if you think about it, meand you, in our lives, we use
about 20 to 100 differentcompanies Uber for travel,
(01:58):
probably like Venmo for sharingpayments across friends, like
YouTube for videos and all ofthese companies have data on us
and we trust them to store thatdata securely, this private data
, and one of the biggest waysthey protect that data is by
protecting the keys to thosesystems.
So, if you're like Airbnb, forexample, airbnb has a database
(02:19):
that has a bunch of homes on it.
They have a bunch oftransaction data.
They have a bunch of data onevery time someone's gone to an
Airbnb and stayed at that place,and all that data is stored in
a database somewhere or in atransaction system somewhere
like Stripe.
And to unlock access to thosesystems, you have digital keys.
Just like how humans havepasswords to like Facebook and
Netflix, so do companies, butthey unlock the data of all of
(02:43):
their customers, and that's whatsecrets are.
Secrets are the keys thatunlock access to your digital,
to a company's digital kingdom,and the reason why I'm on this
call today is because databreaches keep happening, and
they keep happening more andmore.
They've impacted me personallyand I think that there's a
pretty big opportunity for us asan industry to prevent these
(03:04):
data breaches from happeningwith a couple simple things to
do, and that's why I'm on thiscall today.
Speaker 1 (03:11):
Brian, thank you.
I think it couldn't be moretimely.
It always seems like securityand secrets are something that
you know, software engineers anddata engineers are familiar
with, but they don't know.
You know just how impactfulthey are.
Maybe you can also describethat to us.
You know what is the cost of abreach.
Speaker 2 (03:29):
Yeah, really, really
important question.
So, for anyone listening, abreach is basically when data
that should be private gets outin the public, and we've seen
tons of these happen.
Toyota had them, twitch hadthem.
It's becoming even.
Microsoft recently had a prettybig data breach as well, and
there's lots of different waysthat a data breach can impact
(03:50):
both the company and the people.
From a company perspective,it's like a massive brand
reputation hit.
Imagine if you were usingEquifax.
I'm pretty sure you moved offof it To customer churn as a
business.
If you lose that brand trust,you're going to lose a large set
of customers from it.
You're going to have massiveunplanned spend, from a huge
(04:11):
spike in engineering efforts tostop the data breach from
happening and recovering tolegal and PR and insurance.
And then you may also get suedfor your customer, especially if
they consider it negligent.
If you have these keys to thelocks that unlock all the
private data and you are notprotecting these keys, these
secrets, I'd consider thatnegligence and I'd bet most of
your customers would too, and soyou may get sued for it, which
(04:35):
then could also incur someregulatory scrutiny as well.
But outside of all that,because that's all dealing with
the companies.
I think what's actually evenmore important is the people
Like this is something I see alot in the industry of.
They're like oh, we have aterabyte of data or a gigabyte
of data or some ton of data outthere and they always say data
is like this amorphous,ambiguous thing.
(04:55):
But again, this data is my data, it's your data, it's everyone
who's listening on the call dataand that data comes from using
these company services and sowhen this data gets out, it
actually hurts real people,right?
I have a true story thathappened to me, actually pretty
recently, and I can kind of likeillustrate this point.
I live in Austin, texas, and Iwas taking my mom out to some
(05:18):
barbecue and while we were there, I got this call from someone
claiming to be at the TexasCustoms and Borders and they
were saying there's this packagethat's in my name that has a
bunch of illegal drugs and moneyin it, and they're
investigating me and I'm like,all of a sudden, I'm like, oh,
wow, this is when life fallsapart, moment right.
(05:39):
Like you're being investigatedfor something like this that I
clearly didn't do or I felt likeI didn't do, and to validate
who they said that they werethey started sharing all this
information they had on me,where I had been, places I had
lived, people I know, a ton ofdata on me and I was like, okay,
this is a government, who elsewould have that kind of data?
And it wasn't until about 30minutes later, when we had the
lawyers on the phone, that werealized it was a scam.
(06:02):
And not only that, but theywere able to validate themselves
through data that had been inprevious data breaches, like the
Equifax data breach and theTwitch data breach, and not only
, and to compound it evenfurther, they got new data out
of me.
Because I was terrified in thatmoment and I was like I'm
talking to the government, Ihave to be truthful and honest.
And they'd say, oh, this is arecorded line, honest.
(06:25):
And they'd say, oh, this is arecorded line, you're being
investigated, and they will usethat data to attack me even
further.
And the point that I'm tryingto get across here is that when
a data breach happens, it's notlike just the company faces this
brand reputation hit or somelegal problems.
It is real people's lives thatnow all of a sudden get impacted
.
Fraud could happen, they couldget enough information to go in
and steal all your money in yourbank account and one day you
wake up and you're at zero rightLike these things happen and
(06:48):
they've happened to me andthey're going to happen to so
many other people because databreaches keep happening and the
rate of new data breaches everyyear is climbing dramatically,
which means the cost of a databreach is going down, so it's
getting easier and easier forattackers to hurt more and more
people.
Speaker 1 (07:05):
I love that, brian.
I mean, that's like I don'tlove that that's happening, but
I love the way that youarticulated just the amount of
sheer responsibility we have asan industry to really secure the
data.
And yeah, there's all types ofscams going on and it really
seems like the lifeblood ofthese attacks is really the data
, the sensitive private datathat these scammers have on us
(07:28):
as a result of poor securitypractices Exactly.
And why are these breacheshappening?
Speaker 2 (07:36):
It's coming from a
lack of, I think, knowledge
around secrets management.
If you kind of think about it,every software application kind
of has three parts to it Code,compute and secrets.
And we have great tools todayfor code, for both keeping it
secure and collaboration, greattools for compute, like AWS, and
(07:57):
we have very little for secretsoutside of Doppler and a couple
other players in the space.
And because of that, there's alack of knowledge that these
secrets need to be protected.
I can't tell you how many callsI've had with CISOs, chief
security officers or heads ofsecurity where I asked them what
is their strategy for managingsecrets and the first response
back to me in a snap responsewas we don't have secrets.
(08:19):
And I'm like I guarantee youyou have secrets.
If you have a database, youhave secrets.
If you have a payment processor, you have secrets.
If you're sending emails ortext messages, you have secrets.
If you have a payment processor, you have secrets.
If you're sending emails ortext messages, you have secrets
Guaranteed.
And the fact that they didn'teven know that they had it was a
huge problem and that's part ofwhy this PSA, why I'm doing
this PSA.
So a pretty simple question.
I have three questions.
It's like a sniff test and itcan help you.
(08:48):
Do you know where all yoursecrets are?
Because if you don't know whereall your secrets are, you can't
possibly protect them.
The secrets that you have, doyou have access, controls around
them and audit logs?
Basically, do you havepermissioning?
Can you say this person hasaccess and this person doesn't?
And do you know when thosesecrets were read or not?
Because you need to be able tobuild up that audit trail.
If a data breach happens, youneed to be able to say the data
(09:10):
breach happened here and we'regoing to now go fix here.
And then the last question iswhen a data breach does happen,
when you are being hacked andyour worst case scenario just
started happening, which formost companies I would consider
is a when, not an if, especiallywith the security posture they
have today can you stop theattack, can you stop the data
breach?
And it's not as simple as justlike swapping out the lock
(09:31):
Because, remember, yourproduction infrastructure is up.
I'll tell you a real story of acompany that came to us after
they experienced this reallynasty pain point.
They had a malicious actor inthe company and they discovered
this malicious actor, and thismalicious actor, stole all their
secrets and put on the blackmarket.
And I promise you this is acompany where most people on
(09:52):
this call have heard of thiscompany, probably have used this
company.
This is a very well-knowncompany.
I can't share it for exactlythe same reason why, but this is
a true story.
And it took their security teamof three full-time security
engineers six months to swap outall the locks to rotate all the
secrets.
So that's six months wherethose attackers still had the
(10:15):
advantage to keep stealing data.
It took six months of doingnothing else no other security
improvements got made duringthat time but swapping out the
lock, rotating those secrets,and so that's how painful it can
be.
And then, if you have a servicelike Doppler, which is a
first-class developer-centricsecrets manager, we've now
(10:36):
brought that ability to rotateall the locks on the doors or on
the data systems within minutes, so they can click a button and
boom, everything gets rotated.
And the power of that is youdon't need to go figure out
which individual secret got lostor got hacked, you can just
click the all button and knowthat you're safe now.
And that's the real power thata secrets manager can provide is
(10:58):
it can answer the questions ofwhere are all my secrets, who
has access to them and can stopa data breach?
And so that's the root problemthat we have today is that
there's a missing set of toolsthat can very easily be
purchased or made.
I don't care if you use Doppleror not, I just care that the
problem stops.
I need to stop having my dataand everyone else's data in data
breaches.
If you don't end up likingDoppler, give us some feedback
(11:21):
on why, but go with thecompetitor.
I'm okay with that, but we gotto stop the data breaches.
Speaker 1 (11:25):
That's the big thing
we got to stop the data breaches
.
That's the big thing.
Yeah, absolutely.
It's critical to our entiresociety that every company that
has consumer data or data thatshould be private and secured
about the general public istaking all these measures.
And you had this one point inthe beginning where it was like
(11:46):
making vegetables tastes likecandy.
And that's such a good pointbecause you know, when software
engineers or data engineers,analysts, when they're set out
to do a task or build something,they're thinking about you know
making it a a cool feature oran application, and then you do
that code review with them andyou're like, hey, look,
passwords and plain text.
Like, hey, there's you knowother secrets that you're
(12:07):
exposing.
Like no engineer wants to likethink about the.
There's other secrets thatyou're exposing.
No engineer wants to thinkabout the security of the stuff
that they're building.
They just want to make a greatfeature that meets the business
requirement.
So, just to make this practical, you're saying that your
solution does simplify it sothat you can still ship new
products quickly while makingsure that the secrets are
(12:30):
secured and there's goodauditing around them, and
unified or in a way wheresecurity engineers and the
security teams in general havegood control over this.
Speaker 2 (12:41):
Yeah, that's exactly
what I'm saying.
So actually, before I jump intothat, you brought up a really
good point of like why is thishappening?
And it's not the developer'sfault, because that's not at all
what's happening here.
It's that a lot of times, whenyou're going from zero to one,
your job is to get to one.
Your job is to build a productthat people can start using, and
it's only until you reach acertain level of success that
(13:01):
you start to think, wow, I haveto start protecting my success.
And that's where, like usually,a secret manager should get
implemented.
Obviously, I could argue forhaving it day one, but I just
don't think that's practical.
But let's go into what itactually looks to have a secret
manager and the benefits it candrive.
As you mentioned, the goal is tomake vegetables taste like
(13:24):
candy, and we really do see this, genuinely speaking, that every
engineer saves about one to twohours a week using Doppler, and
it's pretty simple how theysave it.
Before, in a pre-Doppler world,they would have an env file
that's on their computer andthis is a file that has a set of
secrets in it, and wheneverthose secrets change because
(13:45):
someone adds a set of code thatneeds new secrets, they have to
then send that over Slack oremail.
And so imagine the days beforeGoogle Docs or Notion, when
everyone had a Word document.
Everyone's changing thatdocument in real time and now we
have to all figure out who hasthe right document.
Doppler solves that entireproblem.
If secrets change, we willpropagate it to your computer
and do real time sync, just likeDropbox does.
(14:07):
So you don't have to worryabout your code all of a sudden
not being able to executebecause you're missing some
secrets and you have no clue whoadded that requirement in those
set of secrets.
So we solve that whole problemon the productivity side and
then on the security side, wedirectly integrate with your
infrastructure.
So whenever secrets change, wewill directly update your
Kubernetes, cluster your AWS,gcp environments and restart
(14:28):
your infrastructure with theright rollout scheme, meaning
you will have no downtime whenyou're doing these new rollout.
And all of this is centralizedin a single place in Doppler.
So you can have a project likethe payments project, a backend
project or whatever the website,and you can have environments
like development, staging,production, and you can have a
different set of secrets foreach environment, and each
environment will be connected toyour infrastructure or to your
(14:50):
developers' laptops, and that'sthe nuts and bolts of it is.
Now you know where all yoursecrets are.
You can set up permissionswhere developers get access to
development and the DevOps teamgets access to production, and
you can automatically roll outthese secrets into developers'
laptops and your infrastructurewhen secrets change.
And you can set up pull requestflows, just like how you pull
(15:12):
requests in code, to not justimmediately push code in
production but have a reviewcycle.
You'll now be able to do thesame thing with secrets too, and
we usually see most companiesintegrate within a couple hours
Small companies like Series Aseed companies usually sub one
day.
Medium-sized companies like aSeries B company a couple of
weeks.
And we have some very, verylarge enterprises, companies
with tens of thousands ofengineers to hundreds of
(15:35):
thousands of engineersintegrating within two to four
months with extremelycomplicated engineering staffs.
So it is possible.
I think that the coolest partabout this problem is that it
can be solved with just a littlebit of time and capital and
resources.
It's not an extremely hardproblem to solve.
You just need the right tooling.
Speaker 1 (15:56):
And that's a great
point.
Companies can take all thesecurity measures in the world.
Theoretically, the way it'sperceived now is it slows down
innovation because you have togo through security reviews and
adding all these additionalsafeguards, your software, and
this can take time and it canadd maybe a year of scope to the
(16:18):
deliverable.
But what you're saying is thatyou simplify it in a way where
it's practical and teams areable to onboard super quickly,
which is obviously supervaluable in the sense that it's
saving time and helpingcompanies do the work of
critically curing their softwareand their customers' data
(16:40):
without really slowing downtheir rate of delivery to the
market, which is great yeah.
Speaker 2 (16:47):
And it's not even not
just slow.
It's not that we're not slowingthem down, we're actually
speeding them up.
That's the really.
That's the vegetable tasteslike candy part.
Uh, we usually see once, twohours per week.
Well, if you start mapping thatout, doppler automatically
becomes a profitable ROI prettyquickly.
Because an engineer, even onehour of an engineer's time, is
far more than we're going toever charge in a month pretty
(17:08):
quickly because an engineer,even one hour of an engineer's
time, is far more than we'regoing to ever charge in a month,
right?
So if you get two hours back ina week, times that by four,
four weeks in a month, you'rereally profitable here.
But also they're going to justship faster because there's less
times that developers get outof flow state.
There's less times where theyhave to say why is my code
broken?
I have to go figure it out andit's broken not because I
changed something, but becausesomeone else changed something
and I'm missing some dependency.
(17:29):
Now that I have to go figure outhow to get that secret, we
solve that whole problem forthem.
And there's tons and tons ofbusinesses built around just
developer productivity, and thisis productivity plus security.
So it's a two-for-one in mymind, and so, yeah, I really do
think that this is a veryaddressable problem that people
can solve.
And again, you don't have touse Doppler Doppler is the only
one that I know of that focuseson the developer productivity
(17:51):
angle too and make sure that itdoes taste vegetables like candy
.
But if you just want yourvegetables without it tasting
like candy, there's tons ofother competitors you can use
too, and as long as you solvethe problem of no more data
breaches, I'll be a happy camper.
Speaker 1 (18:03):
Absolutely.
It's certainly something thatwe need to simplify as an
industry if we really want tomake big leaps in terms of
securing customer data datawarehouses, and you know you're
(18:29):
trying to iterate fast andlaunch these new reports that
the business needs.
The finance team wants to dorev rec on this data.
You know your sales teams wantto know what the customers are
doing, and all this requireslike access to secure what
should be secure customer dataright, and you know this is
another area where I thinksecrets have a big opportunity
(18:59):
to really streamline thatprocess of secure access.
Speaker 2 (19:02):
It's any time that
you need to get a key to a door
and that door has behind thatdoor is a digital system.
Speaker 1 (19:18):
There should be a
secrets manager there to make
sure that there is the rightpermissioning and auditing
throughout that entire story.
Absolutely, absolutely so whatare some of the ways that you
know you help kind of centralizethe secrets management?
Speaker 2 (19:27):
Yeah, so the first
thing we do is we'll pull all
your secrets in to Doppler sowe'll connect with your
production infrastructure youhave today.
We'll import all your ENV filesthat you have on developers'
laptops and we'll give you onecentral view, so kind of like
GitHub, where you can see abunch of repos and in those
repos you can see a bunch ofbranches Same exact thing things
(19:51):
happening in Doppler.
We'll give you a bunch ofprojects and in those projects
you have a bunch of environmentsand then you can start
connecting those environments toyour infrastructure.
So you could say the productionenvironment is going to write to
Kubernetes, the CIC environmentis going to write to GitHub for
GitHub workflows and thedevelopment environment is going
to write to developers' laptopsand then you can go in and you
can see all the secrets and youcan compare them across
environments.
(20:11):
You can set up access controlswhere developers get access to
just development and productionand CICD is accessed by the
DevOps team.
And you can set up policiesthat say, whenever a developer
needs to change secrets in anenvironment they don't have
access to like getting a secretinto production they can set up
(20:31):
a pull request where they canput it up and then someone on
the DevOps team can pull thatinto the production environment
and that's the nuts and bolts ofwhat we offer, plus a very
strong auditing story where wecan push that data into Splunk,
sumo, logic, datadog and a bunchof others to then run analysis
on that data and potentiallyfind vulnerabilities or threats.
Speaker 1 (20:48):
Yeah and that's great
.
So then when the secret isactually represented in the code
in plain text, it's notsomewhere to get access to that
code for some reason and installthe whatever you want to call
it secret identifier.
You can't actually use that toauthenticate with that secure
(21:10):
database or whatever.
That system is right.
Speaker 2 (21:13):
Kind of.
So when the application runs,it will eventually need that
secret, the raw secret that isthe key to that data system, and
so we do most of the time forwhat customers want inject that
secret in.
The big thing is that thesecret's not written in code, so
it's not in disk, it's inmemory.
And so when the applicationboots up, the whole application
(21:35):
is now running in memory and wewill inject those secrets in as
environment variables or as anencrypted file, depending on
what the customer wants, intotheir running application, and
then the application can use itinto their running application
and then the application can useit.
So unless you have spyware thatis inspecting applications and
running applications, it can bevery hard to steal that secret.
(21:55):
And then the most importantpart is it's not running on.
The secrets aren't stored ondisk, so again, they're injected
in at runtime or an encryptedephemeral file that get cleaned
up right after the process ends.
Speaker 1 (22:09):
That's great.
What's your advice toengineering teams that are
either doing very little withsecrets or have something in
place but it's not reallygoverned and centralized?
How would you get started interms of really hardening that
infrastructure?
Speaker 2 (22:26):
I would ask.
The question so I'd figure outfirst is where are all your
secrets today?
So I'd probably run someexercise there and say, okay, so
they're on developer laptops,are they on Slack?
Are they in email?
Are they in my code base?
Are they in CICD, in production?
Figure out all the places wherethey are.
Once you do that, I wouldselect a secret manager.
You can look at Doppler,dopplercom, d-o-p-p-l-e-rcom.
(22:48):
There's other competitors wehave.
If you want to go, look at themas well and figure out what are
the needs you want.
Do you want just security?
Do you want just vegetables, ordo you want developer
productivity too?
Go to Dopplercom, sign up andjust start importing everything,
now that you know where all thesecrets are, and then, most
(23:09):
importantly, clean where theyshould be right.
So like, get them out of code,get them out of Slack, get them
out of email, get them out ofENV files, for example, and have
them all in Doppler and thenconnect that with your
infrastructure and download theDoppler CLI and the VS Code
extension for local development,and once you've done that,
you're pretty much done.
Again, it does not take thatlong at all to solve this
(23:29):
problem.
We're not talking about an AIproblem, where you're training
machine learning models formonths on end and spending
hundreds of thousands of dollarssolving this problem.
It's not an expensive problemto solve.
It's just a tooling problem andthere's very affordable, very
developer-friendly toolsavailable to you to use Doppler
or not.
Speaker 1 (23:51):
Yeah, that's great
that Doppler makes it super
simple and it's not superexpensive to really adopt it
from just a total cost ofownership perspective of
actually deploying it.
The other side of this is thecost of a breach could be
massive, right?
Yes, huge.
Speaker 2 (24:12):
Going back to what we
talked about before, I mean
I'll stay away from the side ofimpacting people because I think
we've talked about that innauseam, but from a pure company
perspective, I mean, if you'respending I don't know 20 bucks
per user, 18 bucks per user onDoppler and you have I don't
know 50 engineers, that's goingto be significantly cheaper than
(24:33):
a data breach where now you'regoing to hire a PR firm to help
you rebuild your reputation.
You're going to hire a legalfirm to either represent you in
a lawsuit from a wide rangingset of customer maybe in a class
action lawsuit, if you're bigenough or just the legal
troubles of cleaning all thismess up.
You're going to havepotentially a lot of customer
(24:53):
churn as well.
So you're going to have loss ofrevenue.
Well, if you're a startup,startups equal growth, which
means revenue can't go down.
The number one rule revenuecannot go down and you will have
that, so you'll have to facethat problem too.
So there are a lot of thingsthat can happen when a data
breach happens that are very,very hard to recover from.
Like if you're looking at twocompanies one set of data breach
(25:16):
and lost loss of respect of theindustry and the other hasn't,
you're going to choose the onethat hasn't had the data breach,
and that's not a mark that youcan remove from company history.
Speaker 1 (25:25):
Absolutely,
absolutely, brian.
Where can people continue tofollow along with your expertise
on this topic?
Speaker 2 (25:33):
Dopplercom
D-O-P-P-L-E-Rcom.
We have a blog there where wewrite all the time about this
kind of topics and you can alsotrack the progress of the
product.
And then you can follow me onTwitter.
I don't post that much.
I actually love talking topeople, but just not on social
media.
It's not really my thing, butthe few times you see me post,
you can follow me on Twitter atVallalunga, brian is the
(25:56):
username, so those are theplaces you can find me.
Speaker 1 (25:59):
Excellent.
Brian Vallalunga, ceo andfounder of Doppler, thanks so
much for joining today's episodeof what's New in Data and thank
you to all the listeners fortuning in.
Thank you.