Speaker 1: Here we go, Warren, how are you just jumping right
into those personal questions?
Speaker 2: I know right who? I can't remember who the guest was.
Speaker 3: We had a guest on it was earlier this year,
and I asked her because we do like a little
prep before we start recording, and I say, you know,
there's no like stumped chump questions. Everything should be laid
back in conversational. And I asked her how she was
doing and she's like, I thought you said there would
be no hard questions.
Speaker 2: I was like, oh my bad.
Speaker 1: I had the right answer here. Actually, I was planning
for this the whole day and then you went and
you asked me, and I totally forgot what it was
that I was going to say here, So.
Speaker 2: You know, thanks for that.
Speaker 3: Yeah, yeah, that's that's why I'm here, joining us back
after a long break. And she just dropped offline. I'll
just foreshadow it. Jillian is back as a co host
on the show, but she's had audio issue, so she'll
be joining us later in the episode, but then also
joining us today as our special guest, Brian valaalonga from Doppler.
Speaker 2: Brian, how are.
Speaker 4: You I'm doing well? Great to be here, dude.
Speaker 3: I'm excited to have you looking forward to this conversation
because we're going to be talking about secrets management, which men,
there's so many different ways to deal with that, so
I'm excited to hear what your take on that is.
But before we get into that, could you give our
listeners a little bit about your background and how you
got to this point in your life.
Speaker 4: Yeah?
Speaker 5: Sure, So, I mean, I've always been a founder at
Hearts Dopplers. I think startup number eight or nine. It's
been quite a journey, a lot of a lot of
companies that now looking back probably feel more like projects.
Speaker 4: But yeah, a lot of failures along the way. So
I'd say is just don't give up.
Speaker 5: But I think for me, where Topla really got started
was I was working and I was working on a
side project at the time while I was at uber
in my free time, and it was a crypto machine
learning marketplace, kind of like all the buzzwords in one
and I could not funding was guaranteed, right, you would think,
and you would think that customers were guaranteed. But turns
out I was just a little too early and none
of that was guaranteed at all. If anything, it was
really freaking hard to get it off the ground. I
felt like pushing a boulder up a hill. You move
one foot forward and slipped five feet back from exhaustion.
Speaker 4: It just sucked.
Speaker 5: And which is funny because like, now there's a company
today that just like is enormously successful doing like ninety
nine percent of what we did. But that's just how
it works, Like you gotta time it correctly, and we didn't.
But yeah, I was working on that for a long
time and I was just getting frustrated, and so I
realized at some point I was never going to be
able to get this thing off the ground, and so
I started looking at the proms I was facing while
running it and managing environment variables, API keys, database URLs,
and other sensitive information that typically is used to like
can figure an application, like I kept struggling with it
felt really weird to share with the contractor. At one
point in time, it's like, oh, are they gonna walk
away with my crypto keys that I can't like really change,
and then all the customers are relying on us to
keep securely and then like we drop crypto one point,
and we were using like Stripe for pay and processing,
and we had the stripe production key in staging the
Stage one and PROD and took us a month to
realize why we weren't doing any transactions. So we were
up in an operational and could not do a transaction,
and it took us so long to figure that. It
was just like so many of these like like face
palm moments where it's like, damn that that sucked.
Speaker 4: And so I.
Speaker 5: Go back to I go back to this in San Franisco,
to this dinner that had a whole bunch of founders
and developers, and I'm like, hey, am I a shitty engineer,
is a world broke? And I just can't tell anymore.
You tell me real problem. And they were like, yeah,
this is a real problem. We're all struggling with the two.
And that's what kind of got us started. And after
that we started building the MVP, which took a couple
of weeks, and on the fourth week we got some
set of customers and then we were off the races
right on.
Speaker 3: I mean, that's a quick turnaround to have to be
onboarding customers on your fourth week.
Speaker 5: Oh yeah, we were. We were like, speed is the
only thing that gives us a permission to survive here
these not We're going to get slaughtered, And so we
just moved incredibly quickly, like there were many many days
with no sleep. I mean, Doppler was you was our
we were the first customer of our own product. Before
we even had a dashboard in a UI. We would
just only use it with the with the API, and
whenever I needed to change secrets, I would literally go
into the database and edit the secrets before the h
the encryption step.
Speaker 2: So it's like, right on, that's awesome.
Speaker 3: So just to put things in context, you kind of
hinted to it, but let's clarify what we mean by secret.
You mentioned, you know, API keys, database, URL's passwords. Obviously,
what kind of things fall into the scope of secrets management.
Speaker 4: Yeah, this is a great question.
Speaker 5: I generally recommend it's anything that configures the application, and
I know that can go even into a little bit
of extreme, Like some people on the call could be like,
what about my port? Is my port really a secret?
And my answer here would be yes. And the reason
why is because if you have to start making a
decision about what's a secret and what's not, then you're
you could be wrong. And the one time you're wrong.
That could lead to the company dying or some like
crazy event happening. So instead, I say, my view is,
anytime you're configuring an application with a variable of some type,
an a pike or poor to a logging statement, whatever
it is, treat all of it the same and treat
it all as the most sensitive thing possible. That way,
you're kind of offloading this decision making and you're saying, Okay,
we're just gonna do the most cure thing by default,
and so we're reducing our chances of a bat event
happening by by what every engineer now kind of like
randomly deciding what's a secret and what's not.
Speaker 3: That's a good point because I think that adds to
a lot of the complexity I've had managing secrets in
the past, is defining Okay, we do our configure variables
over here, but then our secrets you're over here. And
you've just in hindsight now that you said that, I
just doubled my workload for really no no real good reason.
Speaker 5: And usually they end up being like two completely different systems,
and so now it's even harder to track of like
which one to one in which system it's not like
it's like there's like a branching point that you like
can like track that and have a review around it.
Speaker 4: And so a lot of times now you're just hoping.
Speaker 5: And praying every engineer in the company kind of just
makes the right decision at all times, which, like we're
all humans, We're most like at some point in time,
someone is going to make a mistake. The problem is
that mistake could cost the company big time and.
Speaker 4: All of its users.
Speaker 1: Yeah, so a really important point there, I think is
not really worth like really worth diving into for a second.
So I really like this topic because I actually have
a conference talk that I've been doing for a couple
of years now specifically about teaching about secrets management and
all the different strategies out there, and there's like quite
a few of them. Secrets manager, the cloud providers have
key management services, there's like open source faults and whatnot.
And the sad story is the only real strategy that
works in theory is something like bring your own keys,
where things are secured by default, and the number of
providers out there that support that, Like I know we
do at authors like let our customers bring our own keys,
like the number of customers out there that are working
with a provider, even like something as important as Strife
or even some of the cloud providers, they don't support that,
Like you can't bring your own keys to any of
those critical systems. It's sort of ridiculous that this is
the world we live in of only bad options are available.
Speaker 4: Yeah, it is.
Speaker 5: I mean I would say, like where we really now?
I agree with you that it's really we're living in
a world of bad options. Doppler tries to and obviously
I'm biased because I found Adoptler. I'll just call that out,
but like I think that just so anyone knows, but
I do think that, like you can get to a
pretty good state.
Speaker 4: And then I would say where the.
Speaker 5: World's going in a second, one I can talk about
is like the ideal state, but at least a Doppler.
We went through a lot of iterations, like we rebuilt
the product from scratch like three times, and what we
realized is that you're never gonna be able to get
developer ad option unless you make vegetables taste like candy
and vegetables being the security can you be in the
developer productivity.
Speaker 4: Developers are never gonna use it.
Speaker 6: Developers are children in this scenario because it.
Speaker 4: So right, but yeah, you gotta, you gotta. It's it's
really around like are are you taking energy from them?
Speaker 5: You giving them energy in a way, right, Like developers
want to stay and flow state. They want to be
super productive, and if you can help them be more productive,
if you can give them like a tailwind, then they
will love your tool and they'll use it regardless of
the security benefits. But if you give them headwinds, well
they're gonna run away from you because they don't like that, understandably.
And so for us, that was our trick to making
it a tool that developers truly loves. The company gets
security benefits is give them about two hours a week
of productivity games and there's a whole host of ways
we do that. We don't have to get into that
on this call, but like that was the fundamental reason
that I think doubt war has become somewhat successful in
helping developers want to manage their secrets better. It's not
about forcing them to, it's about getting them to want
to do it. And then I think I mentioned before,
like where it's going in the ideal state, we're moving
to this world of like identity based seek, like identity
based authentication. And so the idea here is like with
like we have something like pass key, where like you
can scan your fingerprint or scan your face and get
into another system with just your email address and that
like fingerprint or that face ID, and that's called passkey.
It's getting rolled out across like all these major sites today.
That's gonna start happening with secrets like API keys. Instead
of having this API key, you'll have like this identity
and so the fact that you're on your laptop or
in an AWS cluster, you'll automatically be authenticated to stripe
in the future. And that's like a really powerful thing.
And my guess is it will be like a little
bit difficult to set up without like a proper secrets
manager like Doppler, But once it is set up, it'll
be seamless, like you're just in the machine and it
just works. You're automatically authenticated and there's nothing else you
need to do, and there's now no worry about actually
losing this secrets, which can cause a breach or anything
like that.
Speaker 4: It'll just be secured by default.
Speaker 3: Yeah, for sure, So that scenario sounds to me a
lot like or like very similar to the open id
connect platform. We use that a lot with our GitHub integration.
So the way that works for anyone who's not familiar
with it is GitHub. When your GitHub action runs, it
sends an authenticated request to your AWS environment. ABS validates
that request, and then issues back a temporary set of
credentials tied to a specific role that has been set up.
So now your GitHub action has permissions inside your AWS
account to do only the things that are permitted by
that role and only within the timeframe set by those
keys that were issued to it. And it is a
pain in the pain and he has to set up,
but like, once it's set up, it's so seamless and
smooth and you never have to you never have to
lie to your security guys and say, oh, yeah, we
rotated the keys.
Speaker 2: Absolutely.
Speaker 1: I really liked that you brought this up, actually, because
the canonical name that you called it was open id connect,
which isn't wrang and the like GitHub and AWS jumped
on oi DC as the acronym for it for making
this work, and that's not what open idconnect is at all,
but that's what all these providers are calling it the
canonical term ridiculously is actually known as workload identities, and
they're sourced from the some trusted location. So in this case,
you're having your aw's account trust GitHub as a source,
and then your workload is getting its own temporary identity
which can authenticate to your cloud profighter. And yeah, for Charlotte,
this is the dream come true of bring your own keys.
Workload identity is being able to be passed from wherever
you're running to whatever the third party application is that
you're integrating with without ever needing to do anything else
other than potentially sharing a public key exchange, because I
think that's still going to need to be a manual
step by everyone involved.
Speaker 2: How does that line up with the future as you
see it, Brian.
Speaker 4: It's very close. I think we need some.
Speaker 5: Player, and I think Doppler is going to be that
middle player that kind of acts as like the network
highway for everyone. So I'll give you an example. Let's
just say you're an AWS. We're gonna make it super
seamless to be connected from AWS to Doppler, and so
anytime you're in AI of US, you're automatically authenticated to
Doppler with all the right roles, permissions and all that stuff.
And then you're gonna also want that because you're a
Doppler to be connected automatically to Stripe, to Twilia, to
your database, to the ten thousand other services you're using.
And so now you're gonna get this beautiful world where
you don't have to configure all these individual relationships painfully
in AWS. Instead, you'll set up one relationship with Doppler,
and then Dopper will kind of give you a seamless
way to like manage the rest, and so you kind
of get this like one to one and then one
to many. Right, So, the fact that you're an a
of us, you're not authenticated Dopper, which means you're authenticated
to Stripe, and it all just kind of like works
seamlessly in the background, like Dopper kind of like fades
away and it's like just opera and completely in the
shadows and giving you that authentication to all the services
that you care about. And that's kind of like the
world we see ourselves playing in in the future.
Speaker 2: Right on what.
Speaker 6: You know, did anybody like ever use party lines or
anything when they were a kid and you'd have to
call it and they would direct you to where you
needed to go. And then in the background, you know,
like the nosy neighbor would be listening in on just
everybody's call and would know everything that was going on.
Speaker 1: That nosyas nosy neighbor was my grandma. She was always
on their listening.
Speaker 6: Yeah, I had I had some mounts like that too.
They always knew what was up. And let's stop for
Doppler knows what's up too.
Speaker 5: We try as hard as possible not to know what's
upment you're looking for.
Speaker 2: Right, Nice save Brian Nice.
Speaker 5: I think in like reality, we we'll end up thing is
like we will like offload the like we'll giving because
while the relationship with Stripe or any of these services,
it'll all just get encrypted at the end day, and
we'll just try to make sure that we set up
the encryption in a way that we can't possibly like
read the output of because I like, for everyone's benefit,
we don't want to be able to see that data.
Speaker 1: Yeah, I mean, I think the biggest problem today is
that those serve, those products, those applications that you really
want to have protected, have some of the worst security
and ever. Like you used to Wripe as an example,
and I'm not it's not the worst one there is,
but you can't even like I can't even get SSO
to work with Stripe, like they they don't support it anymore.
Like literally Stripe does not support SSO, And I'm just
like how, like why not? Like I want that to
be integrated into my into my seam system. I want
to be able to authenticate there and have two factor
off through whatever provider I'm utilizing, and it doesn't support it,
so like they don't even support that baseline. So I
have very little faith that in the very near future
strife will support workload identities to.
Speaker 7: Be able to prove that. But I mean, if we
get there, that would be great.
Speaker 1: So far, the number of providers that really support this
is just absolutely minuscule.
Speaker 5: So I have two thoughts around that, because we put
a lot of time into thinking about like how do
we get the community to My gut reed on what's
going to happen is eventually there's gonna be an open
protocol that everyone can.
Speaker 4: Like adhere to that's like pretty easy to use.
Speaker 5: Probably they'll be like SDKs and all the popular languages,
and then some company or a band of secret spanagement
companies are going to put out a leader board and
they're going to show all the companies that do support it.
It will be kind of like the SSO tax website,
and you kind of just like want to be on
that list or don't want to be on that list,
depending on how it's structured. And my hope is that
like that will create enough peer pressure. And then on
top of that, I'm only.
Speaker 4: A bet a lot of money that, like as.
Speaker 5: AI gets more and more sophisticated and can go from
like being a co pilot to like a full blown engineer,
like AI engine years and I'm talking about humans that
are using AI to engineer. I'm talking about an AI
that is fully capable of being an engineer. Those those
AI agents are going to want identity based authentication and
they will push aggressively for it, and I bet that's gonna,
like those two things together will probably lead over time
to like all the big players eventually like doing this
just because they have to.
Speaker 1: I love your optimism, Like it's just it's just so great.
Speaker 7: I mean, because like today we see so many.
Speaker 1: People putting credentials in plain text, let alone whatever else
we're going to call a secret, So getting them to,
you know, go down a different path is a huge
challenge there. And the other problem is like there is
a bit of a standard already around the providers where they.
Speaker 5: Can use it.
Speaker 1: I think everyone could stand up any sort of open id,
but it doesn't give them a lot of like, it
doesn't give them money, like, it doesn't help the businesses
grow to support that as an optional. Less some bigger
players as yeah, we like, if you want us to
use you, you have to support this. And I think
the great example of that is you brought up a
SSO tax, which I think does the wrong thing. I
feel like it's positive reinforcement for all these companies that
do the wrong thing. I see this leaderboard of all
these companies, and now I read that name, and is
there something known in psychology is called preferential attachment. I
see this company listed there, and I forget why, Like
I don't remember SSO tax and you remember the name.
And then months later I got a call from one
of their terrible salespeople trying to harass me on my
personal phone number, saying, hey, do you want to buy
our product? But I heard that company name before, so
now I'm tempted to actually buy their product. Even then,
the reason I know about them is because they were
listed on a site that says they did the wrong thing.
We see the same thing happen with vulnerabilities and data leaks.
You learn about companies because they had a data leak,
and that just actually enforces how great they must be,
because then they send out those emails thing, oh, we're
committed to security, we're going to change things and uh,
and that gives you. That gives you some confidence in
this particular company. So I think there's a special message
that has to be sent that actually does the right thing.
Having a group of standards can work, But if the
companies haven't taken it on themselves to actually implement these,
I don't like. I don't see magically that it's going
to happen in the next ten years.
Speaker 5: Maybe another way to I mean I used to think
the same thing about Pasky's, but now it's getting rolled out.
So but on the flip side, also, this could be
a place where like war compliance comes in, like they
added to the compliance bodies of like if you issue
out secrets, you have to you have to support these methods.
Speaker 3: So let's take a quick step back and talk about
like what are some of the other common strategies that
you've seen for managing secrets, just to help people put
into perspective or like recognize themselves as owners of this
problem even though they may not recognize themselves as that
group yet.
Speaker 4: Yeah.
Speaker 5: So typically the way I see it is they're coming
from a couple of different worlds. One is they're using
something called an eb file or like a plane piece
of text file that has a whole bunch of secrets
on it. That's bad for a number of reasons. One,
those secrets are unencrypted on disc, so like they're very
easy to like steal. Two, they are now shared in
insecure ways like slack an email, again another breach point
that can happen. And three the manua to be coordinated.
Like imagine if you have a ward doc and I
have a ward dooc and everyone else on the team
has the same wartock and we're all editing in real
time before Google docs or Notion, and we have to
all keep it in sick.
Speaker 4: That's like quite hard.
Speaker 5: So another thing we see is like they're only using
cloud providers, which generally works for production, but then they're
using like eethos eb files for development, and like where
the problem really gets bad is like they can't answer
these like fundamental four questions. The first question is like
do I know where all my secrets are?
Speaker 4: These?
Speaker 5: You cannot possibly protect your secrets unless you know where
all of them are.
Speaker 4: Do I have a point? Right?
Speaker 5: Do I have the ability to like access control these
secrets because if you can't put permissions around them, again,
you can't protect them. Very hard to do that when
everyone's just sharing files back and forth. There's no real
permission model.
Speaker 6: There, right?
Speaker 4: Three?
Speaker 5: Do I have logging and auditing around every action that's taken,
including reads?
Speaker 2: Right?
Speaker 5: Do I know every time someone has read a secret
from development of production and everything in between? You'd be
surprised how many times production credentials and then end up
in a development environment. Right, So you need a tract
development too, Like you'll see this all the time where
like developers like, oh productions having an outagy, I'm just
gonna like create myself with produt E and v file
and test production locally real quick. Now you got proud
secrets on your laptop, what are you gonna do?
Speaker 4: Like?
Speaker 5: And then the last one is when you do have
a data breach because something went bad, can you stop
it very quick and very quickly in the orders of
like minutes, Like if you think about how fast data
can leave your system, right, like data can leave your
system like bigabits per second right from a tows, Well
that's the case.
Speaker 4: A couple of minutes of.
Speaker 5: A data breach is actually a really really big deal
at this point, ours is like an like disastrous. And
so if you can't answer those four questions confidently, not
like oh yeah, I can run a piece of paper,
but like I am extremely confident I've bet my job
in my life on these on answering these questions. Confidently
you have a problem and now it's on you to
fix it.
Speaker 3: I like that, that's pretty clear cut. I will not
go on record answering those questions.
Speaker 6: Definitely be my life there, Like I.
Speaker 1: Think maybe much for me, I mean since I since
I guess that leaves me and uh. I run a
technology company that focuses on providing log in and access
control for applications that our customer is right, and so
I feel like secrets is super important for are both
us and are our customers there? And we're pretty extensively
using complex crypto and things like key Management Services KMS
and AWS and some of the other cloud providers to
do that at location, that site based encryption there, and
I definitely don't trust a lot of people to get
that even close to correct.
Speaker 4: Yeah, it's hard.
Speaker 5: It's really really hard, especially if you're like building I
found that if like again, you got to you gotta
get the productivity part, like if you got to make
it super simple and easy to use, where there's no
footgun moments, you can't shoot yourself on the foot The
default easy path has to be the right path. And
that's that's probably like the hardest part that I found
with building this. It's like, at the end of day,
at least for us, it didn't feel like building the
tool that was secure was a hard park. It was
like at our frontish foundational level of like the infrastructure layer,
but building it so that the end the end user
experience to the developer being secured by default, that part
was actually really hard to get right because also because
like every developer has like a differences in mind, and
so like now you have to like support like a
very wide variety of different setups and they all have
to be secured by default, and the most secure thing
has to be the default thing, and so like talking
a little bit about like what a solution would look like,
even if you're not gonna use you don't have to
use Doppler. That's not my job here is to like
sell you guys on that. My job here is to
sell you guys on the problem, and then you guys
should go solve the problems so we don't keep having
data breaches because the.
Speaker 4: Number is only rising. It's rising fast. It's like like
a high growth stock right now.
Speaker 5: What you need is you need a service that centralizes
or a system that centralizes all your secrets in one.
Speaker 4: Place that's encrypted, super super important.
Speaker 5: You need a system that does not encourage secrets to
be on disc so you're reading and if you're reading
from the environment, you immediately clean that up from the
environment after your like frameworks and libraries at booted up.
You need a service that has access controls and auditing
built in, with a really strong audit story there. Ideally
can also push those logs into a centralized logging platform
like data Dogs, Blowing and Zeo Logic so you can
do more robust analysis on it.
Speaker 2: Set up learning, you.
Speaker 5: Need the ability to automatically push the secrets when they
change into your infrastructure, so there can't be a human
step involved, or like, let me file your ticket and
wait three weeks for this ticket to get closed, because
your code's going to get rolled out automatically. So by default,
even without the security problem, you have an outage guaranteed
because you have this race condition of a human filing
fulfilling a ticket versus GitHub automatically rolling that out to
AWS or your infrastructure. Right, they're like one's going to
move a lot faster than the other in the order
of like seconds versus like days and weeks. So you
have to have it automatically rolled out, just like your
code is. And ideally it has to be rolled out
before your code does, so your code has it to
consume when it boots up. And the last thing is
you've got to be able to rotate your credentials, either
automatically or manually very quickly. If you have a data breach,
you cannot learn how to firefight and firefight at the
same time.
Speaker 4: It's too slow. You have to have like your procedures down.
Speaker 5: If you know what buttons you're gonna click, and you're
gonna have to know how fast it takes you and
if you're if the data breach happens and you're going
to take minutes to hours to solve this.
Speaker 4: Problem, you are in a really really bad spot. So
you can do those things.
Speaker 5: Whatever tool you use, you'll be in good shape or
anythink I missed anything, uh.
Speaker 1: Not at all, actually, but the thing that came to
mind is like I'm wondering about. The corollary is like,
you know what other solutions are there that are out
there where you're playing in the same space, and I'm
trying to understand like whether or not it's closer to
say a secrets manager that one of the cloud providers offer,
or open Bow or hashing corpus Vault are say you
know your competitors or whether or not there's something specific here.
Speaker 5: Yeah, So with the secrets managers from the cloud providers,
those are actually partners of ours. So almost all of
our customers are using a TOUS secrets manager and Doppler
and kind of like the the mental model there is
kind of similar to GitHub or get lab or developer
pulls their code down, changes it on their laptop, then
pushes it back up and then one it's ready to
get released to production then get hub or will then
push it to AWS, which has its own repository store, and.
Speaker 4: That gets deployed. Dopper does the same thing.
Speaker 5: We'll like allow you to pull those secrets down, change them,
and then when you're ready to push them up into production,
we will push it to a to B secrets manager
or its pramer store or whatever, using on as your GCP,
and then that will then push it into your infrastructure.
And so it's kind of like the same model there.
So we are very closely partnered with the cloud providers
and most infrastructure companies we support, like I think forty
different infrastructure companies right now, and then on the like
even Kubernetes resupport, which is in the company. It's an
open source initiative, but we support that pretty extensively too,
And then on open VOW, I would say we're more
closely competitive, but I would argue that it really solves
different problems than we do, Like we're looking specifically to
solve secrets regarding API keys, database riels, and other things
that configure your application. I would say open Bow is
more like a generic key store and like you can
put anything sensitive in it, like a photo of a passport,
or social Security number or some medical records, not things
that are like deeply connected to your application and your infrastructure.
I would say they're missing a lot of the layers
going back to that, like make vegetables tastes like candy.
They squarely have the vegetables, but there is no candy involved,
and without the if, you're not really solving the problem.
And so I would say it's kind of like Dropbox
versus Amazon S three. They both do storage, but like
like one is like here's some APIs, go figure out
what to do with it. The other is like a
whole end end experience. It makes it super easy to
securely store managed secrets. And that's where I think we
fit in. So while they're competitive, i'd say we're almost
operating in different market, so like we don't really see
as hyper competitive.
Speaker 2: That makes sense.
Speaker 3: One of the things you keep coming back to that
I really like, it really resonates with me, is making
the vegetables tastes like candy and making the right thing
the default thing. I just think that works so well
because like your target customers, not just yours for Doppler,
but like mine at my organization. You know, I support
the engineering teams, like I try to put in just
guardrails so that they can do whatever they need to
do to get their job done. But then I've got
guardrails in place so they don't accidentally do something that
they didn't want to do, and so they by default
they end up doing the right thing even when they
don't know what the right thing is.
Speaker 2: And I think that's so important to.
Speaker 3: Get to get that right to have adoption so that
you don't have to add this extra layer of technical
expertise and competency on your developers to do the job
that you hired them for.
Speaker 5: One hundred percent agree, Like I would assume like almost
every developer you're going to hire is coming with positive intent.
They want to do a great job. They want the
company to be secure, they want it to be successful.
But a lot of times if you force the question
on the if you force them to answer the question
of like is it secure, is it's not? What's the
best way to secure this? They may not get to
the right answer just because they don't have that expertise.
And so it's important to kind of like abstract that
all way. And developers love abstraction. They love SDKs and
frameworks this is just another one that just equals security. Right,
So yeah, one hundred percent agree with you. I think
one thing we haven't chat about that is worth calling
out is like why should we care? Like why is
everyone on the call? Why should they care about keep
being the secret secure? And I know we've talked a
lot about data breaches for companies, but a lot of times,
for me at least, it feels like the company has
a data breach and they get a slap on the wrist, right,
they get some fine that they can pay with like
one day worth of revenue. They maybe get a bad
press article that turns into a good press press article
later in their minds, as Warren was talking about earlier,
because now they remember the name, and but like, what
is the actual real impact here? Because that doesn't sound
like a lot of negatives right there. That almost sounds
like not that bad. And I think the real risk
is actually to the users. Like it's it's so easy
to forget that every time that we talk about like
gigabytes or terabytes of data, we're talking about usually people's data,
like real people to your customers, and they are trusting
you to keep their data private, like to keep their
private data private and when that when that breach happens,
you're breaching their trust because that private data becomes public
and there's real consequences to that.
Speaker 4: I actually have a real personal story that scared this
shit out of me.
Speaker 5: I just moved to Austin for anyone who cares, and
I took my mom out to some barbecue and while
we were there, I got this call. And the call
it was from someone who claimed to be at the
Texas Customs and Borders and they called me and say, hey,
you're being federally investigated. We found a package that has
illegal drugs and money in it and you cannot hang
up from this phone call. Everything's being recorded and it
will be used against union court a law. And I
was like, oh shit, this is a day my life
just falls apart, Like like I legitimately thought I was
fucked that day?
Speaker 4: Am I allowed to say that? I hope you guys
gonna end it?
Speaker 3: And one of us in this group continuously drops F bombs.
Speaker 2: I'm not going to call.
Speaker 4: That person out. Yeah we never should.
Speaker 5: Uh. But they started asking me all these questions about
like where, like have you been at this address?
Speaker 4: Have you bought these things?
Speaker 5: Like that kind of stuff, like stuff that you'd feel
like owly the government would know, like really owning the
government would know. And like this went on for like
forty minutes where they were just like asking me questions
and I was validating myself on and I was with
my mom. My mom and I were both freaking out,
and at some point we bring on the company lawyers
to like really make sure like I get my I
probably should have brought them on earlier, but I was
scared and.
Speaker 4: I just felt so real.
Speaker 5: And it was only until like an hour and thirty
minutes in when our lawyer when we all caught them
slip up on something, and it was like my lawyer
started pressing them pretty hard, and at some point they
got frustrated and their accent kicked in Texas accent to
like some other accent that I that I was like,
you are not from like America.
Speaker 4: And at that point we realized we were getting scammed.
Speaker 5: But they were only able to get to that point
of trust because of all the data that had been
breached in previous data breaches. My data has been in
like ten data breaches or so like including equal facts,
and so they just had this rich history to lean
on to validate who they are as like an authority,
and I trusted that for like an hour and a half.
And like I have security training. I run a cybersecurity company.
I can imagine my mom, my, sister, anyone else who
has not had security training, like actually go the entire
ten miles and give them everything, and they wake up
tomorrow with like a huge amount of social security problems
and like they're at bank count strained because now know everything,
and like that can happen to real people all the time.
And that's the real cost that we pay when we
mess up and we have a data breach.
Speaker 3: That's a great point because yeah, like you mentioned, you know,
from a corporate level, there's it's almost a net positive
to get a data breach because the fine that you
pay actually turned out to just be like really cheap
marketing is the way it comes out. But like when
you tie it back to and think about like your
mom or your your sister or people that you know,
and you can make it personal like that, that's actually
like it feels like good incentive to take this seriously.
Speaker 1: So I think there's a couple of things there that
are definitely worth repeating. The first one.
Speaker 2: The first one's Brian, what was your social Security number?
Speaker 6: Again to point out real quick, like the fens are
going to come to your door, not call you, although
that would freak me the hell out, and I don't
I don't know that I would consider that on the
phone if I just got a call like that, But
for any anything else, you know, if this is a
scam that's going on, I'm pretty sure they're just gonna come.
They're gonna come get you.
Speaker 1: I know that now, right, Yeah, yeah, Like, just as
soon as the worst a call is that you get,
no matter what it is, just hang up first. That's
that's the number one thing you've got to do. Uh,
if you like, it doesn't matter what happens, You're not
going to get penalized for hanging up the phone.
Speaker 7: I mean, there's no way.
Speaker 1: I And that's the whole point. They try to keep
you on the line because as soon as you hang up,
it's it's actually over for them. The number of times
they have to call back will be a problem. So
for sure, just just do that and uh, if they
don't call back, then no problem.
Speaker 7: And if they do, then you know, you can continue.
Speaker 1: It from there. If you're so worried. If it's so
critical for them to figure out what's going on, they
for sure would call back. Yeah, so that's certainly one
of them. But on the cost for companies, there is
a huge aspect here that So my CEO actually did
a talk couple I think last year about the ROI
on security and she joked that the ROI actually stands
for a return on incident because it's so beneficial to
actually have this happen for you. And the thing is
that it really depends on where you're at. So companies
in the United States, in Russia, and China get attacked
the most. It doesn't matter how big you are, how
many customers you have, it doesn't matter your scale or
your size. You will for sure get attacked. And without
these practices in place.
Speaker 7: You will for sure get breached.
Speaker 1: The other thing that's really interesting is there's a lot
of countries that just don't care about punishing you. So
like the amount of fines that you get because of
like say GDPR, you can actually go look it up.
They're incredibly small, like sub one hundred thousand in most
cases for mass of incisive. There was one recently where
the company did get.
Speaker 7: Sued out of business though, So that's funny.
Speaker 1: And the other thing is that so it's good, you know,
I felt great that you know, someone did something wrong
and they really took the brunt of the punishment. There.
The really interesting thing here is being a company in
Switzerland is there's no professional there's no punishment from the
government for companies from corporate level if we perform or
have a security breach that's a result of executive negligence,
there's up to like fine personal fines the government will
charge you with and there could be other legal repercussions
as well. And that's just so ridiculous. And if you
work in it tar in the United States or in
any NATO country, that's also personal fine. It's it's up
ten million dollars and ten years in jail for having
perpetrated sharing sensitive data that is regulated. So like it's
not even like the company is potentially at fault there.
They don't care. The company for sure doesn't care. But
you as an individual, like there actually could be real
repercussions for you.
Speaker 5: Yep, absolutely, Like we share this with sometimes our customers
all the time of like, it's real negligence if you
don't manage your secrets. You can't just like look away, right,
because again, every single time sometimes up for your website
or does something, they're trusting you, and that trust is
basically broken if you don't actually manage the key to
your digital kingdom. It's like, hey, ere, hackers, take the keys.
That's what you're basically saying, if people protect them.
Speaker 2: Fair point.
Speaker 3: I think another thing, like, I think another thing that
probably is an additional challenge to this is the level
of effort required to get from where I'm at today
in secrets management to like the ideal world that we're
talking about here, because like the question number one you
asked is do you know where all your secrets are
some of the places I've worked in the past, Like
that could be a three to six month project just
to answer that question. And so how do you get
executive buy in to put time and resources towards that.
Speaker 4: It's hard.
Speaker 5: I think one of the first things you can do
that's pretty easy is, like there's a bunch of open
source secret scanners. Truffle Hog is one. Dopper will have
one at some point, I'm sure get Guardians another, and
you can just like put that in the codebase and
it will. You can have it set up so never
admits back out, so like you know that like whatever
your findings are, whatever your code is, it will not
go to Truflehog or gig Guardian. But you can just
get a report and just put that as a check
in every repository as like a commit check. Right, So,
before I can even push to get hub, I'm going
to do a check to scan my code for secrets.
And all of a sudden, if you can't push the
production anymore because of.
Speaker 4: That check, you're probably gonna start pulling secrets.
Speaker 5: Out of product, out of out of code real quickly,
and you're gonna always want to stay in this state
of a green check mark. I EI there's no secrets found.
And that's like one first way I think to like.
Speaker 4: Really move the needle there.
Speaker 5: That is basically free and it takes a couple of
lines of code to implement.
Speaker 4: It's really really quick.
Speaker 3: Yeah, And I guess from there it's it comes down
to like a campaigning issue where you start campaigning for
support to get this as a prioritized project.
Speaker 4: Yeah.
Speaker 1: Yeah, I mean there's something interesting here that could be
really helpful because getting it. So we talked about workload
identities in there being a burden of responsibility on the
API provider whoever they are, to make some changes. The
one that actually helped us a lot at authris was
we automatically revoke found credential so if one of our
customers leaks those credentials online, we will find those automatically
and revoke them immediately. And you may be like, oh, well,
you could break someone's production environment, and that for sure
is true and has happened. And then we get a
support like, oh my god, our production environment is broken?
Why did authors do this to us? And the sound
truth is yeah, I know, okay, it for sure happens.
But the sound truth is that credentials that are found
on GitHub take less than two minutes to become utilized
by a malicious attacker. Yep, that's it. Two minutes. So like,
which do you want? Do you want your production to
be broken or do you want all your data to
be compromised? And if you look at it through the
lenses of I like, well, you should be thanking us
for you know, stepping in here and doing something. And
the scanners are really great. They do this.
Speaker 4: Yeah, do that too.
Speaker 6: Sorry, I was just gonna say, AWS absolutely removed to
credentials if you put them, say in GitHub, which I
have no personal knowledge of them.
Speaker 3: Really, I just heard from red.
Speaker 6: I mean.
Speaker 1: It's almost it's almost funny though, because there were a
couple of people who wanted to do some experiments with
the AWS credentials, and they were struggling to do them
because every time they intentionally leaked their credentials to different places,
ABS kept on revoking them. And they're like, no, I
want to set up a hunting pot.
Speaker 6: Doing here AWS and doing it.
Speaker 1: Intentionally, we're actually doing and yeah, so like in our emails,
we actually say oh, yeah, you know, please let us
know if this was like actually intentional, and then we
can try to figure out how to somehow exclude this
scenario because at least they know that there's like a
solution path here rather than just like automatic credential revocation.
And then be like, but I really want this to happen.
What's going on. My credentials are invalid. Let me go
create new ones and release them again to get up
right like something happened there. I'd like to go through
that five or six times before they learn their lesson.
Speaker 5: We've done the exact same thing with Doppler. If you
if there's a Doppler token found, we will automatically broke it.
I think one step we want to get you even closer, though,
is being able to have some secure way of scanning
your secrets that are in Doppler to see if they've
been in a breach. We do something similar today with passwords.
Were like, if you sign up for a Doppler account
with the password that's been in a data breach, we
actually you and we say you have to use a
different password, and if you log in again and that
in that time since creating your account, your password has
been a data breach, we will force.
Speaker 4: You to change the password.
Speaker 2: That's pretty cool.
Speaker 4: Yeah, I forced.
Speaker 6: People to change it because Google tells me that about
my passwords all the time, and I'm like, oh, but
I'm supposed to be secure. Instead of just rotating, you know,
like various things that I rotate through for passwords, they
don't make me change it, which is which is a
downfall for me.
Speaker 3: Password one, password two, password three, Now I've got to
remember password four as well.
Speaker 6: I know, right, what am I going to do?
Speaker 4: Use a password manager?
Speaker 5: You want like a fifty character a long password that
you could not possibly remember that's what you want.
Speaker 1: So you got to be careful there, because I actually
had to start keeping a list of all of the
websites that told me that I could put a sixty
three character password. But then when you sign up, but
then when you go to enter it, it said it
doesn't match because it's secretly truncating some part of it. Yes,
So like it really starts to get annoying when you
think that they support something to the level of security
standard that you want and then secretly, under the hood
they do something different. And I have a I have
a list of those companies that I've paid very.
Speaker 4: Maybe that have you published it?
Speaker 1: No, that's still private for the moment, and don't jesus,
I got some I got some good stories here. So
one of them would truncate your password down to twenty characters,
but for the two factor off. What it would do
is it would ask you for your TOTP.
Speaker 7: Six character code and.
Speaker 1: Or pen that to the end to make a twenty
six character password and send that in the password field.
So if your password was anywhere above twenty six characters,
you would just get a wrong answer. But if it
was somewhere between twenty one and twenty six, it would
cut out part of the TOTP code.
Speaker 7: And like it wouldn't work, and then you just wouldn't be.
Speaker 1: Able to get in at all. And also what that
does is it tricks your password manager into thinking the
TOTP code is part of your password. And every single
time I go to the site, it asked me if
it want if I should remember that new password update.
Please don't do that. Like, if you're designing a system,
please stop using passwords altogether, honestly, Like we have this
off by default for all of our customers.
Speaker 7: They can't create a password.
Speaker 1: Database unless they come and contact us and justify, like
who their audience is, why they need this, and what
sort of rules are going to put in place, because
it's just so ridiculous in the corporate space, like con
federated logins, oidc samill sso all of those are so
much better. Please just use one of those and don't
use passwords password Like eighty six percent of all vulnerabilities
are a result of password usage, like simcard swapping, you know,
found in breaches, et cetera, et cetera. Like just please,
like passwords are gone, like they're done, they're over.
Speaker 4: I think everyone on this can agree with that.
Speaker 6: I don't know you're still using passwords.
Speaker 3: Or and I don't know that you're like, are you
are you serious about that?
Speaker 4: No, I agree with warn here. I think passwords should
be done. Their time is come. I'm just agreeing with them.
Speaker 1: So, uh, my CEO actually has another talk at q
COON in November in San Francisco that everyone should go
to if you're in the area, and she'll actually be
talking about the fact you do need to have like
somewhere between three and five actual passwords in your life. Unfortunately,
like there's no way around that, and you probably should
have ones that the Rendall Monroe correct horse battery staple
or is it horse battery staple correct. I can never
remember the order of the forewords, that's the problem. But uh,
you don't want to just use a set of path
like words as your password, because now all of the
brute force attacks know that up three to five words
could be your password as well. So you got to
you got to make some changes in there. And uh,
Apple actually has a pretty good strategy for dynamically generating passwords,
where they make a bunch of fake words that are
consonant vowel sounds that are strung together so you can
sort of remember it and use that instead.
Speaker 7: So that's pretty clever.
Speaker 1: But I highly recommend like all those things with symbols
and whatnot. It's it's just it's it's it's over, honestly,
So three to five. If you have more than five passwords,
you're probably doing something unsafe.
Speaker 6: What about my pets names?
Speaker 2: Oh, those are totally in scope.
Speaker 1: Yeah, fantastic.
Speaker 7: I mean for some like now, you've got to tell
them those Callilli.
Speaker 4: Which pets?
Speaker 6: For those Jillian, it could be Eddie pet, it could
be pets from like here to childhood. I think, isn't
that a common security question?
Speaker 2: Like yeah, what's your first dog's name.
Speaker 6: Your first pet, first car, like all that kind of stuff.
So I don't know if it's good enough for the
security question, it should be good enough for my passport.
Speaker 7: It's pretty goodly you brought that up.
Speaker 1: I'm sure Brian has some opinions on this too, likes
just reidelines of the eight hundred.
Speaker 6: I do just come on the show and start trouble
like I have.
Speaker 1: Now it officially says now it actually if as like
you like you shall not force password rotation, like we know,
like that's wrong. For sure. Secrets are a little bit
in the gray area of whether or not force rotation.
Uh is required outside of expected data breaches, but uh yeah,
for sure, like if you were forcing password rotation. Now
there's a government that is more ahead of where you're
at as far as good password hygiene.
Speaker 5: Another thing that I'd strongly recommend is whenever they're asking
for there's like recovery questions of like what, uh, what's
your mother's maiden name or what's the name of your
first pet, don't actually put that go and generate a
new password and put that in like like in like
one pastord begin of multiple fields outside of the used
name password, create another field call that the name of
the question, and then have a type password there and
put in like a sixty character password in there.
Speaker 2: So create a fake family.
Speaker 4: Yeah, really long family.
Speaker 7: I do have a warning there.
Speaker 1: So a long time ago I thought this was a
great idea, and I generated this site to actually dynamically
generate shot two PTY six encoded answers based off of
the questions. So I don't even need to remember the question.
I just copy and paste the question into this generator
and it will generate a shot hash for me to
put there.
Speaker 7: However, it broke me because I was talking with some.
Speaker 1: Customer service experts who would often be on these calls
that have to verify security questions, and they for sure
were like, yeah, we do get people with the list
and when they ask you to verify your question, some
people for sure just say, oh, yeah, it's just some
random characters, like I don't remember, like that's what I
put there. I put random, like it's not a word.
I put random characters there. And that gets by having
put like a password in the security question. So security
questions are over too. But I definitely recommend a real word.
Definitely a real word, but not the right answer, as
Brian said, and to get over this and just store
that in your password manager as well.
Speaker 5: Maybe should be one of those passwords that are like
a chain of words together that you can easily remember, like.
Speaker 4: I would to the park or something like that.
Speaker 1: I got a list of those that don't accept that,
because some of them thought they would be really smart
and there would be a drop down menu of the
answers that you could pick, because you know, that's what
they wanted to go with and I'm like, first of all,
my right answer isn't even here, Like it's like what
was your what it was your first instrument you played?
And I'm like, I couldn't even put the right answer
because it's not listed there.
Speaker 7: So like I don't know what game you're playing.
Speaker 4: Yeah, I'm really curious what like ten years from now,
what this whole identity space is going to look like,
because it's changing.
Speaker 1: Yeah, the rest that I would talk about that because
that's pretty much what I spent all my.
Speaker 7: Day thinking about.
Speaker 1: And I'll say that there is this aspect of past
keys via hardware tokens isn't the future because it's still
too much churn in difficulty and complexity for most people
to get right. And something where the past keys can
be shared between multiple devices is probably correct, but not
the Google or Apple approach, but something way more secure,
and it's coming. There's actually an open standard that allows
for past key transmission between different devices in a secure way,
and I think that will be the first step that
really helps us there. The next one is the root
of trust, like our browsers working for us and making
sure that the security cokens the JWT's the session keys
that we have are device bound and can't be exfiltrated
to an attacker and then reused to generate new stuff
and will always be stuck in cross site scripting land.
But those actual tokens will now be worth outside of
the original device because you'll need the device private key
in order to sign each request. And we're working on it.
It's happening, the right working groups are focused on it,
but you know, it's still a thing that and users
are not going to see a huge impact and say
the next ten.
Speaker 5: Years, yeah, and then once it does happen, you're gonna
have to like roll it out, which will also be
another wave of adoption as well, a slow one.
Speaker 1: It's hard to convince those companies that don't have a
financial stake and doing the right thing to make a
change fundamentally, And so like, I'm really looking forward to
whatever impact Doppler can make on the industry to actually
convince people to move to workload identity verification for every
request and not just because your customer happened to be
someone that had was in Germany and had some ridiculous
security requirements there or required twenty seven KO one or
something or Beta ramp high in order to.
Speaker 2: Get those customers on board.
Speaker 5: We have some active projects around looking into improving the
compliance body so that they are more compassing of like
secure secrets management, and I I think when we make
some serious progress there, our goal is to like make
that more because once you get into SoC two, it's
a beautiful thing like SoC too.
Speaker 4: In a way, it's like if one company saw to,
every company sock to. That's kind of how it has
to work because.
Speaker 5: You have a requirement that all your all your vendors
that use are sought to. So that kind of just
has like this ripple effect where if all the BDOC
companies are sockd to, then every B two B company
sock too. And if we can get in in SoC two,
I think that's a pretty effective way to roll to
roll out what we're looking for. That's the dream at least,
but it's gonna take a long time and a lot
of work to make that happen.
Speaker 7: I I love your optimism.
Speaker 1: I'm just gonna repeat that, like, I just think I
love the existation you have there. It's it's just so
great to hear someone who who thinks that we can,
you know, get down that path and and get to
success that way. It's it's it's awesome.
Speaker 4: Maybe it's not purely optimism.
Speaker 5: I like, at some point, I'm just like this world
is a capitalist structure, and like, at some point, with
enough capital and enough resources, anything should be possible. And
I'm not saying you like bribe, So I'm saying more like,
you just put enough lawyers in the room and you
try to navigate this like it's a political machine, and
eventually you'll get there. And then the question is can
we just raise enough money where we have the force
projection to do that?
Speaker 1: So SoC two for anyone that doesn't have it, ends
up being a write out some policies and prove that
you're following them where compared to actually putting valid security
strategies in place. So it's always going to be a
race to the bottom here, and I think we're going
to see SoC two getting cheaper and less valued over
time as people more people realize that it is a
compliance checkbox. It's checkbox bake security or insurance, it really is,
rather than actually providing a real value. And that's a
sort of a sad fact there, and there's really no alternative,
like maybe that's what we need maybe we need some
sort of non regulatory body that can verify companies are
compliant in performing actual security. And that's sort of hard
because that's driven from like the mindset of the founders
and the executive team and the leadership and money Trump's
security every time.
Speaker 6: See.
Speaker 5: I think sock two is actually pretty great from a
standpoint of like if you're a saw to all your
vendors have to because that just creates this beautiful fact
where the entire industry has some baseline of security. I
think there's just like one critical flaw of sock two,
and that's it's like tax people are like auditors. The
auditors are like literal accountants. Those are the people that
are setting the policies. I just don't understand how accountants
are setting policies around security. It's like completely different fields, right,
Like it'd be like someone who does your taxes is
like the one who's saying you should be secure. I'm like,
maybe leave it to the security professionals who think about
this all day long. If that change, one change happened,
I would bet like the world would.
Speaker 4: Be a lot safer of a place.
Speaker 1: I mean, I'm with you. It evolved from sok one
being a CPA auditor of verification that they would take
actual liability if your finances weren't in check, and then
evolved to actually evaluating different parts of your business reliability,
disaster recovery, business continuity in case of the problem, and
of course that falls into well how do your I
systems actually work as well? So there's a lot there,
but I'm with you. I so to put in perspective
of we use not vitamins but pain pills or painkillers.
The as the analogy, I think governments would have to
pay companies who were secure, Like if you are secure
and you get a certification, I think that if you
got paid, that would be a really driving good driving
factor there.
Speaker 5: It would have to be enough to really move the needle,
because I could even imagine some companies are like, yeah,
even a million year probably.
Speaker 4: Wouldn't move the needle from it.
Speaker 5: I don't know, like maybe it's a percentage. I really
do feel like we don't need to pay them though,
Like I think so two is like the the requirement
that all your vendors are shocked to your requirement I
think is so powerful already that pretty much the entire
industry has adopted it, we just need different people at
the helm.
Speaker 4: Like and I know where it started.
Speaker 5: I completely align you there, but I kind of see
it like Kubernetes, a little bit like that started within
Google and it got so big it got pulled out
of Google into its own body that then could manage
it from then on. And I'm saying, like, sock choose
the same thing. They created something amazing with SoC two,
Let's pull it out of the of the accountants and
let's have real security people run this thing. And like
let's give it a V two or maybe a V three.
I think that would do a lot of good.
Speaker 2: I love.
Speaker 1: Well, it's like, oh, there's so much going on here.
Speaker 6: So I heard a lot with security and very much
like that's somebody else's job. But you guys have like
the nice provided for that kind of thing, which I
guess so I am the problem I suppose in this conversation,
like in general.
Speaker 7: Well maybe that's a good twist though, Like do.
Speaker 1: You feel, like Jillian, you have some comp here to
cause your company to do something different or you have
flexibility to pull in libraries or other providers to help
you support better security.
Speaker 6: Oh yeah, definitely, Like for the most party, they tend
to rely on the you know, like the providers and
things that they work with, because I work with primarily
data science companies, so they're not like technology companies where
they care about the technology in and of itself. So
pretty much as little computing as they can do, they
will do. Like these guys like if they could analyze
the data from their laptop, that's what they would be doing.
So it has to be, you know, like Brian was saying,
it has to be a really easy sell. It has
to you know, it has to be the candy and
not the vegetables. It has to be for the most part,
something they don't even notice happening. It just kind of
like gets bundled into the background. So pretty much anything
on you know, that kind of front, it's it's not
even so much a question for me. I don't ask
them Like I wouldn't ask my clients like, oh do
you want this? I would I would just go do this, right,
I wouldn't say like, oh, do you want for me
to keep your credentials off of GitHub? I would just
keep their credentials off of GitHub in that scenario. So
I do yeah, I do think. So I do think
like smaller you know it providers or consultants, are you know,
like just engineers in general, especially if you're working for
a company where technology is not their focus, you do
have a lot of say in the technology stacks that
are used. So we just got to sell this to
all the developers, right is that? Is that what we're
going for?
Speaker 4: And then eventually we work away at the compliance bodies
and those committees.
Speaker 1: I do have a question about Doppler maybe, and that's like,
what is the minimum implementation you can have here?
Speaker 2: Is there?
Speaker 1: Is it just maybe replacing out the cloud SDKs with
Doppler SDKs for interacting with Supermanager. Is there something else
that has to be done in order to sort of
start getting the benefit right away? Or is there like
a large upfront integration that has to be done to
make it effective?
Speaker 4: Yeah?
Speaker 5: Great, question usually depends on the complexity but the company
that we're working with from their infrastructure standpoint. But I'd
say for like a small startup of like series being below,
they usually get up and operational in like a couple hours.
So like you're usually using some cloud provider like ABSG
Spears your secrets manager, we would directly set up a
sink or an integration and write directly into that, so
you don't need to change your sd case at all.
It's literally just put like a layer on top, which
is Doppler, and then they would download our CLI and
use that for local development. For much larger companies, it
can take in the order of weeks. We've had very
few go longer than a week's even like extremely large entities,
like we have a one customer that's like on a
three year roll out to one hundred and twenty five
thousand engineers, and even them, it was like a couple
of weeks to get them like integrated in their infrastructure.
And usually it's like just connecting dots. It's okay, you're
using a toa secrets manager, you're using GitHub workflows.
Speaker 4: Here, we're just gonna connect all.
Speaker 5: The dots into Doppler and then from there we're going
to add local development through like the vis code extension
we have plus the Doppler CLI, and so it's a
pretty formulaic approach that that's very quick, I would say.
And when you set up those integrations, we'll do bulk
imports as well, so we try to streamline a lot
of it. I'd say, where things get a little bit
more complex, as if we have customers that like to
do everything the terraform way, then we help them kind
of like set up all that stuff instead of in
the UI, but through terraform, So you can actually manage
pretty much every part of Doppler and including all the
orchestration and workflows that.
Speaker 4: We have in Doppler through Terraform.
Speaker 5: And I would say that would slow them, slow them
down a little bit and initially, but then speed them
up on the long haul when they have are like
bringing on like tens of thousands of projects.
Speaker 1: I like that that you really gave credence to that
that using IIC there does does actually slow you down
for development I do thing. It's a lot of truth
there that people don't like to listen to.
Speaker 4: Yeah, it's just like a high upfront cost, but then
it pays difference.
Speaker 1: There's something here where like the IC cloud for the
cloud providers and whatnot. Don't always optimize for easy interactions
right that it's it's to have it be fixed and
maybe work and make it easy to make changes, but
not really quick and easy. Whereas your your console, your UI,
r CLI or optimize for ease of use and getting
to the value as quick as possible.
Speaker 5: Yeah, I would say that I see it's like I
almost see it as like stability insurance, right, like like
you're it's there to keep you stable and reliable and
very predictable, but it's not there for speed.
Speaker 4: Though you can once you have it, once you have.
Speaker 5: Achieved stability, it's very easy to boot up new infrastructure
with it, which can give you some speed benefits. But
sure that's usually come at the cost of a lot
of upfront investment, so it's like paying you're paying down
that or drawing down all all that initial investment over time.
Speaker 1: So I know we opened a huge topic by saying
we're going to talk about secrets management, and I think
we definitely dove into all the different tangents that that
were related to it. Was there anything on this that
you feel like we missed that would have you think
a huge impact for the audience something maybe some special
wisdom there, anything worth sharing.
Speaker 5: Yeah, I would say that the only thing that we
didn't touch on is it's better to start early. I know,
when you're first starting out, you're building a company, you're
all about like I need to get to product market
fits and then at some point you'll need to think
about like, how do I protect the company now that
I've achieved product market fit?
Speaker 4: And what we found is that it's adding security later
on if it's not part of the DNA of the company.
Just almost never works.
Speaker 5: Like you'll you'll take all you'll feel like you're taking
all the right actions, but it won't actually give you
the security benefit you're looking for, and thus you'll be vulnerable.
And so my strongest suggestion would be to use a
secret manager, Doppler or something else day. One does not
have to be the best solution, but just use something,
get used to it, build it as part of the
DNA of your company and of your engineering philosophy, and
then grow with it over time.
Speaker 4: And at least there you're.
Speaker 5: Coming from a stable foundation versus one that's cracky as
how that you're trying to lay layer a building on
top of.
Speaker 4: Because I think it'll save.
Speaker 5: You a lot of headaches and time down the line,
and also I think the right secrets manager, for what
it is worth, will make you feel more productive. So
just calling that out there, that's all I got.
Speaker 2: Seems fair enough. On that note, should we do some picks, Yeah,
let's do it all right?
Speaker 3: Cool, Jillian, I'm throwing you under the bus because you've
been gone for a while. What did you bring for
a pick today? I mean, it's got to be something
cool since you've had plenty of time to figure something out.
Speaker 6: I mean, that's a lot of pressure for what I
was gonna pick. I was just I was gonna like,
I'm looking up my window, it's spooky season, it's autumn.
It's one of the few live action videos before like
cell phones, that my kids will actually watch. And so
that was that was it. Hocus Pocus. Maybe I'll throw
Halloween in there too.
Speaker 3: Just in general, Halloween the movie or the holiday.
Speaker 6: No, the holiday. I don't like any weird horror scary movies. Okay,
Like hocus Pocus is as scary as it gets for me.
Speaker 1: I don't know why you're laughing, will like that.
Speaker 7: That Hocus movie for sure traumatized.
Speaker 1: Me as a child, like that was not I didn't
I didn't appreciate that experience. That was very troubling, especially
where the cat. You know, there's an animal death in
the end, and that's that's always struggling for me.
Speaker 6: Oh, that's true. I was I was okay with hocus Pocus.
The never Ending Story for some reason is like the
kids movie that really freaked me out, so we can
like bond over our shared trauma of nineties movies. Like
Another Day.
Speaker 1: I actually liked ever I did a story, you know,
a different world, was, you know, sufficiently interesting.
Speaker 4: I liked back in the day, Halloween Town if you've
ever heard of it. It was like a Disney series,
a couple of movies. But I would say it's great
for kids. That's magic in it, a little scary, but
not too scary.
Speaker 6: I love all the kids Halloween movies and stuff like that.
They're so much fun.
Speaker 2: They are, all right, Warren, how about you? What'd you
bring for a pick?
Speaker 1: You know, I thought for sure you were you were
gonna tell me to go first again, which I you know,
I've just gotten so used to.
Speaker 7: I'm happy to just do it from here on out.
Speaker 2: You're gonna follow your sword for us?
Speaker 1: Yeah, I'll just I'll just admit that. So what I
was when you asked me how I was doing, I
had the whole, the whole episode to actually think about that,
and what I came to is, so I guess I
sort of have two picks today. The first one is
I'm today is like one of the first days of
my short little intermittent fasting that I do every quarter
where I just like don't eat any food for three
to seven days and it just makes me feel so
much better. There's a bunch of health benefits associated with
taking a break from eating, and I feel better usually
by the time I'm done, so like sort of like
a full cleanse in a way, I highly recommend there's
no negative health impact at all from doing this. I mean,
it's sort of psychological. It's nice to think like, oh,
I don't have to eat like all the time. So
I really appreciate that so great since I started doing it.
And I think my real pick for today is going
to be a book, because I always pick a book
I guess called Drive by Daniel H. Pink that talks
about the truth of what motivates us and how we
as humans get motivated and what actually we use to
drive our desire, what we work on, what we find
enjoyment in. And the one really important learning that I
pulled out from the book is that you will always
lose happiness in something where you expect a reward for it.
So if you really like doing something, and then you
make that your job, and your job pays you to
do that thing, you will actually lose motivation to perform
that action. Which is sort of a sad story, but
I think there's a lot of truth in it. When
you start associating money with the thing that you're doing.
Speaker 3: Yeah, I've seen that happen in my own life, and
it's surprising.
Speaker 2: You're like, oh, damn, I used to enjoy this.
Speaker 3: What happened in retrospect, You're like, oh, I turned it
into a job.
Speaker 2: That's my bad.
Speaker 6: You should not monetize your hobbies, right, throw that out.
There's life advice. Just don't just sit down and crochet
your scarps or whatever. It doesn't have to make the money.
Speaker 1: Now, I feel like there's a story there that I'm
gonna want to have to hear at some point.
Speaker 3: You're gonna have to do like a non DevOps episode
at one point just to cover some of these topics
we keep bringing up. I think, so, Brian, what about
you would you bring for a pick?
Speaker 5: I got too. The first one is perplexity. It's kind
of like the new version of Google, and like imagine
you're trying to like answer a question like how do
I cook steak with an air fryer? And like instead
of googling that where you can get a bunch of
links you have to go through, it kind of just
gives you the answer. So it's like chatbut but with
like search capabilities and advanced reasoning built in. There pretty
much hasn't been a question that I've thrown a where
it failed at Like it's it's really good, including like
what happened yesterday in the news, like really really recent stuff.
It does a great job of analyzing and you can
ask you like very complex chain of thought questions where
like like I find a lot of times I'm searching
for something and then I'll have a follow up question
and so now I need to like ask another query
into Google. And this is like you just it's like
almost like a thread of questions so you can get
like every follow up question has all the context of
the first question or the previous questions.
Speaker 4: So I really love perplexity. I've completely shifted.
Speaker 5: Over to using perplexity for almost any knowledge based question
of like how do I do ex er? What do
I think about this? Or what happened in the stock market?
Why did this price go up?
Speaker 4: Whatever? It is.
Speaker 5: The second one is pickaball. I love pickaball, love it
so much. I try to play like five days a week,
two to three hours a day. It's hyper addicting. I
burned like thousand to thousand, eight hundred calories a session.
It's like a really high mount of calories. And it
doesn't feel like a workout at all. Like it's probably
the first workout sport that I've played that I genuinely
love doing and I don't and I'm not just like
waiting for it to end. So if there's any people
like that out there who have, like will always wanted
to get into sports or always wanted to get in
the gym, but always felt like I never really connected
with them, try pick a ball. There's something magical about it.
Almost everyone I show two falls.
Speaker 6: In love with it.
Speaker 3: Yeah, I've never played, but I know people who do,
and it like the level of passion amongst the pickleball
community is pretty wild.
Speaker 4: Isn't like?
Speaker 5: And it's very uh, it transfers well, like you you
you catch that bug where you're like, I just got
to be playing today.
Speaker 4: I did not play at all, and I feel guilty.
I don't know.
Speaker 5: It's it's I The last time I felt this level
of passionate and drive for something was like building a company.
So let's use like a pretty high bar for me.
It's like, uh so strongly recommend.
Speaker 3: Right on excellent, So I'm gonna pick because we were
talking about this before we started recording the episode. The
book by William fortun one second after. It's a science
fiction novel that talks.
Speaker 2: About the struggles of.
Speaker 3: A community after an emp or electromagnetic pulse bomb was
detonated over the United States and so that wipes out
all of our modern infrastructure, and it's I just found
it to be a fascinating book because of the things
that happened. It's you know, you don't normally think about,
and it was a it was well written and very
engaging throughout. So if you're into that kind of stuff,
definitely a cool book to read. And I think that
brings us to the end of the episode. Brian, thank
you so much. It's been great having you on a show.
Very insightful and yeah, crap, now I got work to do, thanks.
Speaker 4: Man, right.
Speaker 6: Having this episode with a checklist?
Speaker 2: Yeah, no kidding for real.
Speaker 3: Jillian, it's nice to have you back on the show Warren,
as always, thank you for being here and Brian hope
to hear from you again.
Speaker 2: Best of luck with Doppler and keep in touch. We'll do.
Speaker 3: Thank you all right, you bet, And to all our listeners,
thank you for listening and we'll see you all next
week