77. Inside Augment Code: Why security starts at line one (with Dirk Meister)

Hello, everyone, and welcome to another episode of the security podcast of Silicon Valley. I'm one of the hosts, John McLaughlin. I'm joined with the other host, Sasha Sienkiewicz. And we are super excited to have an amazing guest with us today, Dirk Meister, a founding engineer at Augment Code.

Welcome to the show, Dirk. Thank you for having me. So Dirk, we're here on the security podcast of Silicon Valley. We've got the ear of the security community.

Do you think of yourself as a security person? I actually don't. But a lot of the work that I do is security and thinking about it. I'm like founding engineer at Augment.

I work on like all the different things, especially from the product side. I did a lot of the initial product security work and tried to like ensure that the right foundations are built that like we can later extend on. But I'm not a security expert. I'm just really passionate about like getting that right for us and for our customers.

Why do you think it's important to get security right in the beginning of the life cycle of the product, especially when the company is just starting? Often security is seen as an overhead, but maybe there are good reasons why we should think about this certain security controls earlier than later. I think that two answers to that. One is it's my general approach to software engineering and startups.

Like when you get your architecture right, everything else becomes easier later. When you get your architecture wrong, everything becomes harder and harder. And I have seen companies dying on these kind of mistakes. So I think a bit of thinking in the beginning, what do we want to do?

What do we want to end up? Even when the limitation is not there yet, but like getting the architecture right will pay extreme benefits later. And that extends to security when you get your security architecture right in the beginning. And that extends to later, for example, when we think about like PAI, which like is not security itself, but closely related to that.

When in the beginning we introduced the right swim lanes and systems and we know where data flows. We know where data flows all the time. Two years in, we don't have to find out like, oh, some data is there and some data is a different place. And somebody has like a shadow IT somewhere.

When you build in the right infrastructure that people can work with and you think about where we want to have data. And what do we want to store where? And what is PAI and what's not PAI? Later, when it then becomes really important, it's much, much easier.

Otherwise you have to like step back and like do a redesign of everything and like stop the company and nobody wants that. And then when you redesign, it usually has an associated costs and cost is not only in money, but also time that it takes to redesign. But the foundational work that you just mentioned, it probably helps to build trust with the potential prospects and customers. Because we're not talking about the checkbox security.

We're talking about the proper implementation security controls. I think that's completely right. For Augment Code, we store the source code of our customers. That is really important to them.

So security is like checkbox for them, but it's also not checkbox for them. And I think when we as Augment talk with them, like this is what we're doing. This is really how our architecture is built. It builds trust with them.

Like, yes, these are people who like know what they're doing. And we can trust who clearly have thought about it. But it's not like some afterthought that came in like two years later because like something happened. But like from the beginning, oh, yeah, how do we secure the customer data is part of the DNA of the company.

Yeah. Do you think there is a question that is related to security and privacy? The enterprise should be asking but are not asking today or not asking as often? I don't know.

I think that too often security is checkboxes. And the checkboxes are because this is like the great standard between companies and the prospect. This is what you are supposed to ask. But I think 80% of these checkboxes are going to the core questions.

The questions that you cannot answer with a checkbox are, I think, the most important questions. But like, is the architecture built for security is not a checkbox. It's complex. It's messy.

It's not easy to answer. But I think is then really in product security, this is where the difference comes in. And I don't have a solution how to make that easy and how to scale that for like companies and for prospects. Yeah.

I love the idea that security can make a real impact and can be very specific. You mentioned product security. And you mentioned engineering. And I think when engineering is done with a discerning eye.

When you engineer a system with intent and you know what you're building, it's almost like you can isolate out the components that matter the most. And when you do that, you're actually like trimming things down, making a system simpler. So that almost you can just look at the system as simple as it is, as it needs to be, and have a much more confident answer that something is secure. And I'm super curious to hear, like in those early days, as a founding engineer at Augment Code, was there anything in particular, an engineering problem that kind of turned into a really nice engineering solution and resulted also maybe in a benefit for security too?

We use this concept we call proof of possession, where an engineer has to prove to the system that they're in possession of a certain source code file, and then only we are reusing it. So like when the 90% of the repository that is shared between all engineers and the company, that proves that they have access to the shared files, and then we complete out of that. And the 10% they only have access to, then only they can get access to because nobody else can prove possession of that file. People shouldn't put secrets or tokens into files.

But let's also be honest, that sometimes happens. So like when Augment would complete off somebody else's private files that nobody else has seen, maybe they're preparing a bash command or something like that, that would be horrible. So that's even this in-end enterprise that we keep the different engineers separated was an important decision on that side. So this is proof of possession that came early on out of a product question, but I think it ended up really beneficial from a security perspective.

Those technical controls are super important to speak about the actual security controls, not checkboxes. When we are talking about trust, building trust with a potential prospect or an existing customer. This goes back to the original question. What are some of the things that customers should be asking but are not asking?

And questions around how do you protect the crown jewel? Because essentially a prospect is given the control over that crown jewel and it hands it over to the processor. I don't know how to frame that as an easy answer. Like when you ask anybody, like, is your engineering taking security seriously?

Everybody will say yes. Nobody will say no. And security is always a shade of gray. Like we try to do our best and think through it and do all the controls.

It's still not 100%. Like people might find like an attacker always might find one bypassing through the back door that we didn't, that nobody thought about. What customers should do, what prospects should do is try to get past the checkboxes and see if people, like the best thing companies can hope for is that people take that seriously. Not only in the security team, they might be facing this because security teams are only like, what, 5% of a company, 10% of a company.

So 90% of the company is not a security team. 90% of the company is not the people that think about security all day long. If you have a company where like 10% really care about security and 90% don't care about security, that's not a good state to be. So I think the question people should ask, and I don't know what that question is, is getting past the security team and try to gauge what is really the culture.

What is the culture outside of security team? Because if only security team cares, you lost. And I think that's why I don't see myself as a security person. I am part of engineering.

I'm not part of the security team or like only caring about security. And most people who care about security at Augment are part of all normal teams, normal engineers. And like splat around the organization, have their ears on the ground. That's a very important mindset.

I've witnessed firsthand the culture at Augment where every engineer, every function that is executed, it's taken with the context of the security controls in mind. How do we do things making sure that the ground rules are well protected? And I've been on the other side of this equation where you have a large organization of engineers and a silo security team. And for that reason, you hear about the security champion programs where you constantly try to come up with ways to share that security knowledge.

And that can be quite challenging. It can be time consuming to train or retrain the culture. I think in Augment, right, the security culture is coming in from the top. The culture there is all from, you know, it's coming in from Dietz, it's coming in from Igor, it's coming in from Guy.

And an incredible foundation and the values are clear that customers are turning over their source code to Augment into the cloud, right? And they're doing that because they want to enable their own engineering teams to enjoy this magical new technology of AI. And all of the AI augmentation to enhance engineering productivity, to help us write code, to help us write code more securely, to help us write more code more quickly with less bugs on complex systems. And AI can be used to enhance all of that.

But at the same time, like, there's an adoption issue, right? Like, okay, if we're going to put all of our code up in the cloud, what's going to happen with it? And a lot of the customers, I imagine, especially in the enterprise space, are cognizant of those security requirements because those are their crown jewels, right? We're asking a lot.

We're asking a lot from our customers. Like, we're asking from them, hey, if you want to use our product, we need your source code to really, really work. That's a big ask. And everybody understands that.

It would be easier if we could do the same quality without it. Everybody would prefer that. It's just that with, like, large code bases, complex organizations, our system relies on indexing the code base, getting all the intelligence out of it, getting the patterns out of it. But, like, we understand, oh, we are asking a lot of these people.

And we are aware of that. And we want to earn their trust that they allow us to do that. So I think that's the realization that, like, it's not something that people do, like, nilly-villy. It's not something unimportant to them.

It's something that is really important to them. And we want to earn the trust as good as we can from as many people as we can. Yeah, that's right. That's right.

And so to go back to, like, the strength that proof of possession brings to the table, you know, if there is, you know, to just highlight what that means, because I was digesting it as we were talking about it. And it seems like even if someone has access to my augment code account, and they're malicious, and they try to trick augment code into using the context that's already been uploaded to produce code suggestions that would defalge this very sensitive IP, they would not be able to. Just because you have to prove that you have that context already. You have to prove that you have locally on your machine all of the IP that's already there.

So it wouldn't even be possible. That's completely right. The access token, in some sense, is, like, you can use a system. You can, like, defraud us of, like, using it more than you're allowed to do or something like that.

But, like, you cannot, with just the API token of a user, you cannot get access to the source code the user might have uploaded six months ago or a minute ago. So the access key, the access token, the access to the system does not grant access to the system. It does not grant access to the source code that was uploaded before. I think that's an important difference.

That's an incredibly powerful, like, security position to take because now, like, a breach of credentials, which usually would mean, like, a breach of, like, the data that the credentials are protecting, is not actually a breach of the data. It's just breach to the access of the system. You could steal, like, the service, but you can't steal any of the data that's been uploaded unless you already have that data locally, which, like, you don't. Yeah, that's correct.

So in security, you know, we have these journeys that we go on. And, you know, if we back up just a little bit, I would love to hear what inspired your entrepreneurial journey. Because being a founding engineer, you're really there from the beginning. You know, you're thinking through a lot of these technical challenges that are being faced with these new use cases.

And they're delicate. They're just as important to the success of the company as, like, the marketing or the sales deals that go through. Because, as you put it, like, you know, these types of decisions can make or break whether or not something is even adoptable, whether or not something can scale, whether or not it will hold up. And so you have a really interesting story.

I feel like there's just, and I'm curious to hear what's the inspiration behind it. I've worked in, like, later startups most of my career at Pure Storage, at Databricks. I joined Pure Storage when, like, 60 engineers, 200 employees. So I was always in startups, but not as early as Augment.

I was never in the room in the beginning. And then, like, the excellent founders and Igor and the VP of Engineering and other founding engineers contacted me three years ago. Hey, we are starting this new thing in engineering productivity, combining this AI. I said that, yeah, like, it's a new thing.

I can really build something from scratch with these excellent people in a field that I'm really passionate about. So I'm always scared about engineering productivity. I said yes to that. Let's do something, like, as early as possible with a really excellent team.

I just got into interest in insecurity a bit earlier when I was at Databricks. I was working on the CI team. The CI team at Databricks was responsible for all the test infrastructure, testing, what is tested, but also what can be merged to the main repository, what can be deployed. And at the time, Databricks was going through their fat-moderate certification process.

And the CodeMCI team, the team that I led as tech lead, was, like, directly in the middle of this transition of, like, okay, we really have to think every decision we are doing through. Can you bypass these checks? Who is bypass these checks? How do we do glassbreaking?

How do we merge? What code is secure and trusted? What code is not secured? And, like, that was a really fascinating journey.

And when I made the decision to leave Databricks to join Augment, it really stuck in my mind when it became clear that Augment is as security-relevant and asking as much as from our customers as Databricks asking from their customers to take these lessons and apply them as much as I could at Augment. No, I love that. And so it sounds like it was the team and it was the problem space and it was the challenge. I feel like you like a good challenge.

Yeah, exactly. Like, this is a technical challenging area. It was new. It's doing something at scale.

It's doing something for, like, helping engineers. And I think engineers need every help they can get. Like, software engineering is getting so complex. And anything we can do to make their life a bit easier, I think, is worth doing.

I couldn't agree more. And so if you were to think about, like, everyone brings, like, different strengths to the table. Maybe you think of them as superpowers. I'm super curious.

What's your superpower? What's your strength? And maybe there's a story about where it came from. For somebody who works in startups a complete career, which is, like, sometimes a wild west and a tech that is taken really freely, I always try to keep it under control.

I think we discussed about that. I think architecture is, like, so paramount. If you get that right, everything becomes easy two years on. If you get that wrong, everything becomes a problem two years on.

And, like, five percent of thinking on a whiteboard or on a piece of paper can save you months and months later. And what's the point of, like, building a product that people like when it doesn't work? But obviously, balance this. We have to get to product market fit.

We have to iterate fast. We have to take that, but in a conscious way. And, like, try to balance these things. But, like, I think this was really, like, a founding experience to me.

That, like, when you are in a start, even a startup, architecture matters. Building the right foundation matters. Because it's a marathon. Startup's a marathon.

It's not a sprint. It's, like, you have to survive the first year. But the first year is only the year before the second year. And the fifth year.

And the tenth year. We want to build a sustainable company. And, like, that's always a pitch. And sometimes this pitch, you lose a battle and you win a battle.

But that's how I approach startups and tech that in startups. And security is a part of that. That, like, when you get your security fundamentals wrong, you will have big projects. Big rewrites.

A lot of pain later to get that back under control. And when you get them right, a whole bunch of other amazing things start to fall into place, right? You get faster product market fit. You can see adoption in larger and larger organizations.

You can land certifications. Even though those are just checkboxes, you can land them much more quickly. Like SOC 2, Type 2. Augment, I think, was the first engineering AI platform to get their SOC 2, Type 2, right?

I think so. I also think Augment was the first to ISO 4 run, 0, 0 run. But I might get these numbers wrong. I never can remember the numbers.

Yeah. Yeah, it was the first to 4, 2, 0, 0, 1. For sure it was. Like, all of the big players got it.

Augment code was actually, like, the 30-some first company in the world to get that. And instead of now rebuilding the architecture and security architecture, our engineers can now focus on, like, building the next features, which I think is huge. What everybody has built in the early days is now really, I think, reaping the benefits of more productivity now, faster scaling, in a way that enterprises can trust. Like, we.

. . I think Augment doesn't talk a lot about the companies that are users, but some of them are, like, really security-conscious companies, sometimes to a painful extent. But, like, they take this really serious, and they look at us, and they look at us deeply, and they come out and say, yes, that's the one that we can trust.

And to go back to that foundational security done right, and we're not just talking about checkbox security, we're talking about proper security controls implementations. Once you get that done right, it's very easy to add on top of it. For example, we can talk about customer-managed keys. That was a fairly swift addition, because the architecture, which we have today at Augment, enabled a fairly swift addition of customer-managed keys, and maybe, Dirk, you can talk a little bit more about that.

Why it is important, and what does it enable? So customer keys are important, again, from the trust of our customers to us. And the trust here comes from the ability to not trust us, that they trust us when we want to move away from these people because we don't like their servers, that they lose access to the data that they uploaded. And this ability to walk away is, I think, what can help customers' prospects to interacting with us.

And that means they have a cryptographic key, they give us access to it, and when they wipe our access to it, we lose access to the data. We don't have to delete anything. Even when we don't delete anything, it's useless to us. It's just now render bytes.

And it's essentially a secure cryptographic deletion at that point. It's a cryptographic deletion. Even when we don't delete the files itself, the data itself, the rows itself, they are useless. As you said, this was because we knew exactly where our data is and how our data is stored, and we controlled the access to the data very tightly.

It was a really swift project to add CMK to all the customer data in a way that's transparent to the customers. It wasn't a rewrite of the system, and now we have to find all the data and something like that. What are you most proud of in the system or in the entire Augment platforms? I think what I'm most proud of is how we try to manage the trade-off between security by default and having no access to it and the ability to gain access for support.

So it's not about shutting everything down. It's leaving this controlled holes that on customer demand, we can look at the pieces that are relevant to the customers when they ask us to look at it. And we have like the security architecture where engineers now can ask for access, write their business reasons, link to a support ticket, whatever they need to do, and get access for a limited amount of time to the data. And.

. . To a limited set of data, right? It doesn't just give you access to the entire data.

Right. To a specific set of data, not the complete data. Right. And this goes back to the foundations of the proper security controls built early on.

You have this multiple turnkey approval process that you have to go through in order to gain a limited visibility into the systems only when there is a reason for it, like a customer opens a support case. And this is not only at the front end, it's not a check that we do one time at the. . .

on the support website or in the extension. It's a check that we do to the lowest level of the database access so that it's much more difficult and I hope impossible to circumvent. A great addition to thinking about security and layers goes all the way down into the infrastructure and connects to very real business needs. So yeah, that's absolutely something to be most proud about.

I'm super curious, you know, oftentimes when you're doing a startup, you're in a startup, things go so fast, but there's always going to be challenges, you know, with doing stuff like that. I'm curious from your story, from Dirk's perspective, you know, in your entire journey, have you had like a most difficult day in your entrepreneurial journeys? The most difficult day as a startup engineer for me was like leaving Databricks because it's a company that I like really like, they have like a fantastic culture and they're doing so well and like leaving a company that is doing well as a startup engineer is always like a difficult choice.

But when the opportunity for Augment come along to build something for the first time in an era that was really new at the time, like nowadays, like everybody talks about AI for code, it's a really hot topic. Companies use it a lot because they see the benefits, but at the time that wasn't clear yet. It was really building something new that hasn't been done before. And I think AI for code is like the biggest change in how software's written at least in the last 30, 40 years.

Being part of that was something that I really wanted to do, but it was a really tough day. Yeah, you do have to be a little bit, I mean, you have to have that very entrepreneurial, like sense of adventure just to jump in there and be like the world is changing and I have decided I want to be part of that change. Yeah, exactly. And building it was like really good people and building something new and exciting.

Working at a startup, being a founding engineer is, when you're getting comfortable, you're doing something wrong. it's always about like challenging yourself into new areas. Like what I have believed six years ago that I would work on like product security, no. But it's about like digging into something new, like understanding a topic as good as possible by like working with good people, learning from good people, learning from all the information that is out there in the internet and like dig yourself into a new topic, learning it, understanding it, and then like applying it in a way that people like you didn't know three years ago.

So like it's always challenging yourself. What's the most proud or the brightest day that you remember from the day you joined, Augment, the new startup, the new kid on the block and between then and now, what's the brightest day that you remember? I think it's always the darkest days too. Like when you have a big outage and everybody comes together.

It's not the days where everything works because it just works. That's the job. But like when something doesn't work and that happens. But like when engineering and leadership comes together and you work through a tough problem and restore something and it's the toughest days and you're like, oh, what is going on?

But then you figure it out and you can restore the service. So it's like this camaraderie that comes out of this intense pressure that the hardest days, but also then the most fun days to look back at. These are the kind of days where I'm like looking back with most fondness. We have a lot of listeners who are in different stages of their professional career.

What advice would you give to a new engineer that started their career maybe a couple years ago or maybe an entrepreneur that is looking to start a new project? What would be your advice? I'm an old schooler. I still think that foundations matter.

That like understanding computer science is not only overhead that leads you to for your first job where you then like do TypeScript, but that it helps you building a foundation and appreciation for the science that we are working with, even in a startup, even in this situation, that AI for code, again, it's about balance. If you trust the AI completely and you don't read it anymore, you will be in quite a problem in six months. And I built as somebody who professionally built AI for code solution, but it's still the engineer on the other side that is important. This company is called Augment and not replaced for a reason.

We believe that. So like the use the AI as much as possible, but don't trust it. Always have a healthy amount of mistrust. Be curious, stay learning, understand the fundamentals.

I think the fundamentals of computer science, the fundamentals of software engineering are probably the only things that are not changing with AI. Like how do you work with people to get requirements out of them that actually hold? Like when you talk to a salesperson, they have a completely different language than the engineering language. How do you communicate with them to actually understand what they're really asking from you?

It's a skill set that is valuable now. It's a skill set that was valuable 20 years ago. And I deeply believe it will be a skill set that is really important to you in 20 years. 100%.

It's the fundamentals. The fundamentals are the only things not changing with this new advent of AI. I think more and more emphasis will be on architecture, will be on collaboration, will be on requirements, will be on decision-making. But these fundamentals of software engineering stay the same.

I think they will become a much, much bigger part of what we are doing in our software engineering job in the future. And now you can focus on bigger picture. But like you mentioned, the communication and collaboration skills are very important. And they will become even more important because it's crucial to understand where the business is moving, where the sales team is, where the marketing team is, and how do you connect all of these data points and build the bridges and build the comprehensive solution together as a team.

And I think this is the journey of all computer science for the last 50 years. Like 50 years ago, or in the 60s, people could sit in like a small corner and like write their own tar implementation or something like that. But like software engineering is a team spot. It has been for a really long time and it will be even more.

And like, even when you look back to like the classical papers about software engineering of like Fred Brooks, 96, 1970s, 1980s, and you look at it and like they solved the same problems in the 80s we solved now. People think so much is changing and AI will change so much even more. But I think the, like, what does it mean to do software engineering? What are the fundamental problems of software engineering?

That's not changing. If you could go back in time and meet your younger self, would you? And would you have any advice for your younger self? I was always a bit this mask kid in school and like, why do I have to learn writing?

It's boring. And why do I have to learn English? I live in Germany. Who will use this English ever?

I think I was wrong. I think writing is a really important skill. Writing is a form of communication. And I think I noticed for a really long time.

And in school, I found it incredibly boring to look at languages and writing. And it's something where I really learned in university then. When there was a lot of technical writing courses in university where I at least had understood more the importance of that. But getting to that earlier is something like learning how to write, learning how to understand your audience when you're writing is something that I would give myself as advice, but also some advice that I give to a lot of the people I mentor, the early career people of this is something that is so important.

It's something to really focus on. And this is where I would plug a couple of the articles that you have recently produced for Augment. And what I would like to highlight super quickly is the importance of delivering the core concept in as little words as possible for it to be very easy to understand. You've done a lot of great articles explaining very plainly and simply what it is and why it is important.

You want to do it as simple as possible without going to the point of lying. You can explain everything simple, but sometimes you're like, that's actually no longer true. You want to explain something as simple as possible, but not cross the border. Find the right abstraction for the right person, but stay true and always remember that the people interacting with you, people reading something, it's all about trust.

And if people don't trust what you're doing, if people don't trust anymore what you're writing, it's the most important thing, especially I think in security. Is there a person or an event in your life that made the biggest impact on your career? I was lucky to always have mentors in the companies that I joined from the earliest days where I was like after high school, I started working as like a software engineer apprentice and I found great mentors there that then guided me to like go to university later.

So I didn't join, I didn't go to university directly after school, I did, it was an apprenticeship in Germany, but people were like guiding me to go further and then this went up to like a PhD and then when I joined companies, always look out for the people who are smart and know what's going on and like find mentors and I was always lucky to have people who could guide me and help and it's always about like getting the right help, standing off the people, standing on the shoulders of giants and like learning and understanding what is going on. But yes, it's not one person in a career, it's a set of people who are I'm really grateful to have worked with in all the different companies.

And this goes back to working together, we are individuals, but we work so much better in company. Exactly. A person, like one of the things for me is that augment is like we have an office and we come together and we go to a whiteboard and like people are completely different, I completely respect that, but for me it's so much easier to collaborate with people when you see them face to face and stand beside them and have your coffee talks and I know that's different people have different preferences, but maybe because I'm a bit of an introvert by nature, I think it actually helps to have the forcing function of being in the same room to become collaborative.

Thank you for sharing your experience not only with the Augment team, which you are a big part of today, but also with all of the audience on the show. And we thank you so much for joining the show, for going back into the history about your development as a security professional, about your career, about your career path, and all of the advices that you shared with the new engineers that are looking to start their careers. Thank you for having me. It was a great pleasure.

Thank you everyone for joining another episode. It has been an absolute pleasure and we look forward to the next episode. And many more. Thank you, thank you.

Thank you, Dirk. Sasha. Thank you.