Episode 31 of The Security Podcast of Silicon Valley aired on August 3, 2023, with Jon McLachlan hosting. The guest was Sergey Stelmakh, head of security engineering at Yugabyte, the company behind the distributed database YugabyteDB (Podbean, Apple Podcasts, Spotify). The episode is called “Sergey Stelmakh, Head of Security Engineering at Yugabyte, on Innovation vs Security in Startups.” Jon and Sergey worked together at Symphony Communications, Jon says on the tape.
Most of the hour is about one question: can security say yes to new things? Sergey’s answer starts with what a no means. When security says no, he said, there’s something it doesn’t understand yet, and that leaves room to talk.
“there is a room for us to have a conversation and come up with a reasonable solution.”
Sergey Stelmakh, at 20:17
This page follows the conversation in order: a section for each part of it, fifteen figures, twelve clips from the tape, three LinkedIn posts, a talk on YouTube, the full transcript, and five tools: a quiz, a scorecard for whether your controls keep their intent, a calculator for what a control change costs in meetings, a timeline, and a to-do list. Where the decodes of the tape disagree on a word, the transcript puts its best guess in brackets, and the page doesn’t quote or retell those words.
Puzzles first
Jon asked how a PhD student in mathematics ended up in security. For Sergey it was a natural step. As far back as he can remember, he loved solving puzzles. Puzzles led him to mathematics and programming, and to applied mathematics at university. He started programming on the side, and over time moved into software engineering full time. He kept picking up hard tasks, and those turned out to be in security, cryptography in particular.
“for the past decade, it’s been my primary focus.”
Sergey Stelmakh, at 3:10
His LinkedIn lists a PhD in mathematics from Belarusian State University, where he was an assistant professor from September 2008 to March 2013. Then came software engineering at Boolba Labs, Android and then security architecture at Symphony from 2013 to 2017, platform security architecture at MuleSoft from 2017 to 2021, and Yugabyte from June 2021 (LinkedIn).
Jon pointed out that mathematics and cryptography overlap, and that most security people don’t go that deep. Sergey said it helped. He has seen people from many backgrounds in security, and a PhD in applied mathematics, he said:
“is definitely not a must-have to build a career in cybersecurity.”
Sergey Stelmakh, at 4:21
One database you can scale
Jon asked what Yugabyte does better than anyone else. Sergey described a distributed database for cloud-native applications. It’s strongly consistent, he said, and has both SQL and NoSQL interfaces, so you can scale one database and run both kinds of queries against it.
Wikipedia describes YugabyteDB as a transactional distributed SQL database for cloud-native applications. Its YSQL interface is compatible with PostgreSQL code, and its YCQL interface is a Cassandra-like API that, unlike Cassandra, is transactional. The founders, former Facebook engineers, came together in February 2016, and the company open-sourced its commercial features under the Apache 2.0 license in July 2019 (Wikipedia).
Engineer your way out
Before Yugabyte, Sergey drove security architecture at MuleSoft. He joined, he said, before it went public, and Salesforce acquired it shortly after. Helping merge MuleSoft’s security function into Salesforce was a unique experience, he said, and a lot of fun. Wikipedia dates MuleSoft’s first day on the New York Stock Exchange to March 17, 2017, and Salesforce’s $6.5 billion acquisition to 2018 (Wikipedia).
When that transition ended, he looked for a company with an engineering culture. For him, that’s about the way a company solves its problems.
“So you face a challenge, and you engineer your way out.”
Sergey Stelmakh, at 7:13
MuleSoft was that kind of company, he said, and so is a company of developers who write databases. Nobody in software is more hardcore than they are, in his view. Jon heard a theme: hard problems, solved in an elegant way. Sergey agreed.
“my job matches my personality.”
Sergey Stelmakh, at 8:26
He thinks everyone’s career should line up with who they are as a person.
Twenty areas, one focus
Jon asked about a typical day. Sergey tells people joining the field to keep a diagram of the security domains pinned to the desk.
“There are like twenty different areas, where cryptography, for example, is just one of them.”
Sergey Stelmakh, at 9:28
“I primarily focus on DevSecOps and application security.”
Sergey Stelmakh, at 9:36
That covers vulnerability management, threat detection and response, security architecture and a secure software development lifecycle. Supporting compliance is part of his daily routine too.
Yugabyte posted a session from its Distributed SQL Summit in October 2022 on the security questions a chief information security officer asks about YugabyteDB. The presenter introduces Sergey as Yugabyte’s senior director of security engineering, answering questions in the chat. Its chapters cover encryption, encryption in transit, encryption key management, authentication and authorization, and a secure software development lifecycle.
Compliance gives you a framework
Jon called compliance a challenging space. Sergey said it can be, and that many people in security misread it. Engineers complain about compliance requirements, and he thinks that comes from misunderstanding the idea.
“The compliance gives you a framework”
Sergey Stelmakh, at 10:22
The framework makes sure you don’t miss anything as you harden the company’s security posture. Left alone, he said, he’d spend his days on cryptography, key management and certificate management.
“it forces me to think beyond that.”
Sergey Stelmakh, at 10:49
“How do I keep the supply chain secure? How do I roll into production without unnecessary risk?”
Sergey Stelmakh, at 10:56
Six months after the episode, Sergey wrote up a framework of that kind for Yugabyte’s own product: the CIS Benchmark for YugabyteDB. What happened after the tape has it.
The hardest days
Jon asked for Sergey’s best day at Yugabyte. It’s still ahead of him, he said, maybe the day the company goes public. The hardest ones come several at a time.
Security is a risk management business, he said: you weigh many variables and try to put a number on the risk. When a breach hits the industry, the uncertainty is high and you work with a lot of unknowns. His examples were Log4j and LastPass. Log4Shell is the Log4j flaw reported in November 2021 and exploited as a zero-day (Wikipedia). In late 2022, LastPass user data, billing information and vaults were breached (Wikipedia).
When the LastPass news broke, his team worked out within an hour that Yugabyte wasn’t affected. It was a tough hour.
“you always assume the worst.”
Sergey Stelmakh, at 12:44
Jon said that staying calm and focused through days like that, positive without being over the top, and compassionate about everyone’s emotions, is what makes a good leader. On episode 17, Sean Cassidy described the Log4Shell days at Asana, when he asked engineering to drop everything and help.
Big shops and small ones
Jon remembered the Symphony team. It was a startup, everyone was in the same boat, and the people made the difference. He encourages people to try both big and small companies, and he prefers the small ones. Sergey said it depends on the stage of your career. After a few small companies, a big shop with a big budget can look good. A small company shows you more: you see many different functions up close, far more than in a big corporation.
Jon added that each side brings what the other is missing. Big-company experience helps at a startup, and startup experience pays off many times over at a big company.
Security versus innovation
Then Jon raised the reputation security has. The security people show up in a meeting to say no, add requirements, stretch the timeline and ask for threat models of new features. He has been in awkward spots like that, and he has always wondered whether security can enable innovation, change and speed. Sergey turned the question back to him. Jon thinks so, hopes so, and is optimistic. Sergey said he is more skeptical, and laid out why.
“Security is all about mitigating risks”
Sergey Stelmakh, at 16:25
“Innovation is actually quite opposite.”
Sergey Stelmakh, at 16:33
Innovation takes risks to make a big improvement in some area, so the two have radically different goals.
He compared it to the well-known inverse relationship between security and usability, where you have to balance one against the other. Security versus innovation works the same way, he said: the job is to find the balance that lets a company be innovative and secure at once, and to place each security control where it belongs.
He offered a guess about how a large company can lose the lead in a new field: a meeting where a few people from security call the plan too risky, and the company holds back. Companies can get too cautious and misread security risks, he said, and security people need to admit that it happens.
A no means we don’t understand yet
Security people tend to say no, Sergey said, when they don’t know something. His advice was for the people on the other side of the table, the product managers Jon joked about: a no means there’s an unknown. Until they hear the firmest version of no, there’s room for a conversation and a reasonable solution, as in the quote at the top of this page.
On episode 95, Pranava Adduri of Bedrock Data made a related point: if security doesn’t offer a sanctioned path, people find a shadow path.
Reinterpret the control
For practical advice, Sergey said he leans toward detection and response. Then he reworded Jon’s point that startups take risks. In a smaller company, he said, you have more freedom in how you read a control.
“you have an ability to better interpret security controls.”
Sergey Stelmakh, at 22:49
You can keep the control’s protection for customers, so the product stays secure, without making it a burden on the engineering team. His example was a control from years ago: allowlist the IP addresses of internal infrastructure. That was when Kubernetes was becoming the standard way to run microservices.
“What is the IP address in that environment? It’s just ephemeral.”
Sergey Stelmakh, at 23:27
So his team kept the control’s intent and changed the method: Kubernetes network policies.
“it’s more secure than the original control was.”
Sergey Stelmakh, at 23:51
The Kubernetes documentation describes network policies as rules for traffic between pods in a cluster, and between pods and the outside world. A policy can pick the allowed peers by pod or namespace with a selector, or by IP block, and it only takes effect if the cluster’s network plugin enforces it (Kubernetes).
In big, bureaucratic companies, a change like that is much harder to push through, he said. Jon agreed: a small company has less red tape. If you’re the person the company listens to on security, you can suggest something, show a demo, and win over the other 20 or 40 people.
“do a demo, and boom, you’ve just won over the other, like, 20 people or 40 people”
Jon McLachlan, at 24:31
Sergey has done it at small and mid-sized companies, and at Salesforce too. It’s possible at a big company, he said, and the price is the number of meetings you need to have. This page’s calculator, What does a control change cost in meetings?, puts numbers on that.
FedRAMP ranked first
That reminded Sergey of a project from his MuleSoft days: FedRAMP certification. It was painful and interesting, he said, and the most sophisticated security framework he has seen. He has also seen the Department of Defense’s impact level certification on paper, and called it extreme. As a framework a company can work with, he put FedRAMP at the top.
Meeting it takes a lot of thought, a lot of security controls and a lot of engineering work. Jon remembered the detail and the auditing, perhaps one of the most rigorous processes, he said, and a special cloud environment that lagged years behind the regular one, so a product might not even run there. Sergey said it’s much better now, with more or less feature parity.
FedRAMP is the US government’s program for assessing, authorizing and monitoring the security of cloud products and services. The government calls it FISMA for the cloud, and a 2011 memorandum from the Office of Management and Budget set it up (Wikipedia).
Jon added why it matters. A big pile of data at a social network is people’s lives too, and cyberbullying is real harm. With defense contracts and government agencies, a breach can put lives on the line. Sergey pointed to the human factor in recent breaches: people inside an organization who share more than they should. Technical controls are pretty good, he said. Jon agreed, and added that a phone call or an email that wins someone’s trust gets you a long way. Security awareness is the key to success, Sergey said, so security has to spread awareness and explain what the profession is about.
Questionnaires from another era
Jon came back to innovation from the customer’s side. In large business-to-business deals, he said, customers can be security’s best friends. Their security teams ask where your SOC 2 and your FedRAMP are, so security isn’t the bad cop. The growth of the company depends on its security posture.
“Sometimes customers can be our best friends.”
Jon McLachlan, at 28:51
Sergey wanted to add some spice. He works with customers, and he sees their security feature requests. Some of them make no sense. Jon had seen one the day before: a prospect asked whether his company would get its permission before adding any new vendor. With 100 customers, he said, they’re not going to ask a hundred people’s blessing to add something like Datadog to their stack.
Sergey said that’s the tip of the iceberg. Some security questionnaires come from the nineties, with questions 20 years old.
“They’re not real anymore.”
Sergey Stelmakh, at 31:07
When he gets a request like that, he looks for the business justification.
“I would rather accept feature requests from business customers rather than security teams of those customers”
Sergey Stelmakh, at 31:22
The customer’s security team isn’t in that business, he said. It has a list of requirements, and it rolls the list over to you. Yugabyte’s Legal and Trust Center lists its certifications in one place: SOC 1, 2 and 3, ISO 27001 and 22301, PCI DSS and the CSA Trusted Cloud Provider program (Yugabyte).
Everyone wants an HSM
One customer request Sergey kept running into was a hardware security module. He isn’t a fan of the technology.
“if you ever work with HSM, you wouldn’t like that technology.”
Sergey Stelmakh, at 32:08
An HSM is hard to manage, he said, and it’s built for a few particular use cases, such as running a public certificate authority. Jon asked him to explain it for people new to security. It’s a piece of hardware that does cryptographic operations for you, Sergey said, and it looks like a regular rack-mount server. It’s also hard to operate: shake it too much and the keys stored on it are gone.
Wikipedia describes an HSM as a physical device that safeguards and manages secrets, above all digital keys, and performs cryptographic functions. Some respond to tampering by deleting their keys (Wikipedia), a practice called zeroisation (Wikipedia).
Crypto companies keep their private keys in HSMs, Sergey said, and if something happens to the HSM, the keys are gone. He wondered how they back the keys up, since every extra copy is another place the key can leak. On episode 69, Riad Wahby of Cubist described one answer: an HSM holding a master key, locked to a secure enclave so that only known code can use it.
For a customer who wants one secret kept in an HSM, Sergey said, it doesn’t make sense.
“I see that everybody seemed to be obsessed with that.”
Sergey Stelmakh, at 34:06
Yugabyte uses key management solutions in its place.
“There are plenty on the market.”
Sergey Stelmakh, at 34:31
Key management covers the whole life of a key: how it’s generated, exchanged, stored, used, destroyed and replaced (Wikipedia).
Built at Symphony
Jon then pointed at their own past. Build a chat system with all of its keys kept inside an HSM, he said, and that’s what he and Sergey built together.
“this is what we built at Symphony Communications together.”
Jon McLachlan, at 34:45
Sergey called it a great technical project for a narrow use case. Jon said it opened up sales to the big names in finance, but it never broke out of that vertical, and then Slack came along, easy to use, and took the market. Sergey named it in three words: security versus innovation.
Jon called Symphony a special case. The big financial institutions were its first customers, sat on its board and owned the company, and investors who are also your customers cut both ways, he said. Sergey agreed: they had a strong vision, and they pushed it.
Wikipedia describes Symphony as a messaging and communication service for financial firms. In October 2014, Goldman Sachs and 14 other financial institutions put $66 million into setting up Symphony Communication Services (Wikipedia). Salesforce announced it would buy Slack on December 1, 2020 (Wikipedia).
Top challenges, in their own words
Jon asked what Sergey looks for when he builds a team: a favorite interview question, red flags, green flags. His approach has gotten simpler over the years.
“interview toolkit kind of simplified a lot.”
Sergey Stelmakh, at 36:39
He asks candidates for the top challenges they’ve worked on, and lets them sink or swim. If they can’t swim, he said, you see it right away. He doesn’t like quizzing people on technical areas they may not know, so the candidate picks the area and they have a conversation there. He thinks that’s fair, and it shows the professional.
“a conversation between two professionals”
Sergey Stelmakh, at 37:39
There are several rounds, he added, including coding interviews, so the technical skills get tested at another stage.
Not sure means no
Jon asked how the team decides when someone raises a concern: is there a process for championing a candidate or challenging the fit? Sergey’s rule: if you’re not sure, don’t hire, and everyone in the room has to say yes. Jon called it an AND gate. He has also seen places where a champion could carry a candidate over a concern. Sergey said hiring isn’t a democracy, and a no still needs a reason.
“if you say no, I expect justification.”
Sergey Stelmakh, at 39:17
Not liking someone’s outfit doesn’t count, he said. A yes needs less explanation than a no, and a no comes with the red flags and what the interviewer found. He also looks for a mix of skill sets, and he builds a team spread across time zones.
“we need a better time zone coverage.”
Sergey Stelmakh, at 40:17
That isn’t always possible, he said, so it isn’t advice for everyone. Jon added that a team spread out that way brings a lot of diversity with it.
Stop doing what you don’t like
Jon asked what Sergey would tell his younger self. He’d love to have a beer with his younger self, he said. They’re different people now. The advice would be to look after his mental and physical well-being. Jon asked how he’d sell that to a younger Sergey. He might fail, Sergey said, but he has a motto he has followed since early in his career. If there’s something you don’t like doing, stop doing it, even without an alternative lined up, because you need the time for something else. He would start following it even earlier. Jon put it back in his own words.
“if you don’t like doing something, stop doing it.”
Jon McLachlan, at 42:50
Jon has changed his mind several times too, and he has always landed somewhere in security. He plays a game with himself that’s close to Sergey’s motto. One day will be the last day. If he wouldn’t pick today to replay as that last day, he asks himself why, and changes whatever the answer is. Sergey said it’s a good one, framed a little differently.
Teach someone today
Jon asked for parting words. Sergey asked listeners to spread awareness.
“teach someone about security today.”
Sergey Stelmakh, at 44:37
Jon posted the episode on LinkedIn the evening it aired.
Jon on marrying innovation, which takes risks, with security, which reduces them.
Jon McLachlan · August 3, 2023
What happened after the tape
The CIS Benchmark for YugabyteDB. On January 31, 2024, Sergey announced that the Center for Internet Security had published a benchmark for YugabyteDB. It covers release 2.20 of the self-managed product, and Yugabyte says YugabyteDB is the first distributed SQL database to complete one. It has two levels: settings any system should have, and stricter settings that may cost some functionality (Yugabyte). It’s the kind of framework he described in Compliance gives you a framework. In his LinkedIn post he thanked the team behind it, among them Sasha Sinkevich, a co-founder of YSecurity.
Sergey thanks the team behind the CIS Benchmark for YugabyteDB.
Sergey Stelmakh · January 31, 2024
Detection for the managed service. In January 2024, Yugabyte wrote up how it chose detection tooling for the infrastructure behind its managed database. Its requirements started with intrusion detection, file integrity monitoring, malware detection and log search, and it found a gap in Kubernetes support among the tools it looked at (Yugabyte). It picked the self-hosted version of the open-source tool Wazuh (Yugabyte).
PCI DSS Level 1. On March 14, 2024, Yugabyte announced PCI DSS Level 1 compliance for its fully managed database service. Level 1 means an annual report from a Qualified Security Assessor, quarterly network scans, and penetration testing (Yugabyte). Sergey shared it with a note: “It wasn’t my first rodeo with PCI”.
Sergey congratulates the Yugabyte team on PCI DSS.
Sergey Stelmakh · March 14, 2024
A data layer for agents. On May 7, 2026, Yugabyte introduced Meko, a single data layer for the knowledge, memory and decision traces of multi-agent systems, behind one MCP endpoint (Yugabyte). Sergey shared the launch on LinkedIn.
At KubeCon. On November 10, 2026, Yugabyte said on X that its engineers and architects were at KubeCon + CloudNativeCon North America 2026 (X).
More on this site. On episode 76, Michael Nov of Prime Security said security is not always in the room when design decisions get made. On episode 95, Pranava Adduri compared good security to the brakes that let a driver take a corner at speed.
Did you catch it? A seven-question quiz
Seven questions from the episode. Each answer links the moment in the transcript or its section.
Quiz · seven questions
Did you catch it?
Pick an answer to see whether you caught it.
-
What led Sergey to mathematics and programming?
a. Puzzles, and they led him to mathematics and programming. See Puzzles first.
-
What does compliance give you, in Sergey's view?
b. "The compliance gives you a framework" Transcript, 10:22.
-
After the LastPass news, how long did Sergey's team take to confirm Yugabyte wasn't affected?
c. Within an hour, and it was a tough hour. See The hardest days.
-
When security says no, what does it usually mean, according to Sergey?
a. "say no if we don't know something." Transcript, 19:36.
-
What did Sergey's team use in place of an IP allowlist for internal infrastructure?
b. Network policies, which met the intent of the old control. See Reinterpret the control.
-
Which framework did Sergey rank first of all he has seen?
c. FedRAMP, which he worked through at MuleSoft. See FedRAMP ranked first.
-
How does Sergey's team make a hiring decision?
a. Everyone in the room has to say yes, and a no needs a reason. See Not sure means no.
Do your controls keep their intent?
Eight questions on how your security program says yes, and whether your controls protect what they were written to protect. Each tip quotes the tape or paraphrases it, and links its section.
Scorecard · eight questions
Do your controls keep their intent?
Answer for your company as it runs today. If two answers fit, pick the lower one.
-
When security says no to a new feature, what happens next?
- The no is final
- Sometimes there's a follow-up meeting
- We name what we don't understand yet and work out a solution together
"say no if we don't know something." See A no means we don't understand yet.
-
Do you know the intent behind each control you follow?
- We follow the wording
- For some controls
- Each control has a written intent, and we meet it in the way that fits our stack
"What is the IP address in that environment? It's just ephemeral." See Reinterpret the control.
-
How does your team treat compliance?
- As paperwork for auditors
- As a checklist before each audit
- As a framework that makes sure we don't miss anything as we harden
"The compliance gives you a framework" See Compliance gives you a framework.
-
When a widely used vendor or library is breached, how soon do you know whether you're affected?
- Days later, if at all
- Within a day
- Within an hour
"you always assume the worst." See The hardest days.
-
How do you detect and respond to an attack in progress?
- We'd find out from a customer
- We have alerts, and nobody owns them
- Detection has an owner and a response plan we've practiced
For practical advice, Sergey leans toward detection and response. See Reinterpret the control.
-
How do you answer customer security questionnaires?
- From scratch each time
- From a shared bank of answers
- From a published trust page and standard documents, and we push back on questions that don't apply
"They're not real anymore." See Questionnaires from another era.
-
Where do your encryption keys and secrets live?
- In code or config files
- In a secrets manager, for some systems
- In a key management service, with an HSM only where a use case needs one
Yugabyte uses key management solutions, and an HSM fits a few use cases. See Everyone wants an HSM.
-
How does your security team decide on a hire?
- The hiring manager decides alone
- A majority vote
- Everyone in the loop says yes, and a no comes with reasons
"if you say no, I expect justification." See Not sure means no.
Security says no, and the no ends the conversation. Start by writing down the intent of your top controls, and what an engineer needs from security to get to yes.
Security and engineering talk, and some controls still follow their wording more than their intent. Next, review your controls against your stack, and time how long a vendor breach takes you to triage.
Your controls protect what they were meant to protect, and a no starts a conversation. Keep a public page of your certifications, and practice the first hour after a breach elsewhere.
What does a control change cost in meetings?
At a big company, Sergey said, you can still reinterpret a control. The price is the number of meetings. This calculator counts them.
Calculator
What does a control change cost in meetings?
Six numbers: the control changes you push through each year, the meetings each one takes, the people in each meeting, how long a meeting runs, what an hour of their time costs, and the share of meetings a working demo could replace.
One change takes 30 h of people's time, which costs $3,600. A year of changes: 360 h, at a cost of $43,200. A demo that replaces 50% of the meetings gives back 180 h a year.
The calculator counts meeting time only. It leaves out the engineering work of the change itself. The defaults are placeholders: put in your own numbers.
From mathematics to Yugabyte
Sergey’s roles, Yugabyte’s milestones, the industry events from the tape, and this show. Filter by topic.
Timeline
From mathematics to Yugabyte
- Assistant professor
Belarusian State University, to March 2013 (LinkedIn).
- Boolba Labs
Software engineer and project director, to August 2013 (LinkedIn).
- Symphony
Android tech lead (LinkedIn).
- Symphony Communication Services
Goldman Sachs and 14 other financial institutions put in $66 million (Wikipedia).
- Security architect
Security architect and lead back-end engineer at Symphony, to March 2017 (LinkedIn, on this page).
- Yugabyte's founders
Three former Facebook engineers come together to build YugabyteDB (Wikipedia).
- MuleSoft goes public
On the New York Stock Exchange (Wikipedia).
- MuleSoft
Platform security architect, to June 2021 (LinkedIn, on this page).
- Salesforce buys MuleSoft
For $6.5 billion (Wikipedia).
- Open source
Yugabyte releases its commercial features under the Apache 2.0 license (Wikipedia).
- Salesforce and Slack
Salesforce announces it will buy Slack (Wikipedia).
- Yugabyte
Head of security engineering (LinkedIn).
- Series C
$188 million at a $1.3 billion valuation (Wikipedia).
- Log4Shell
Reported in the Log4j logging library and exploited as a zero-day (Wikipedia, on this page).
- Episode 17
Sean Cassidy on the Log4Shell days at Asana (episode page).
- Security questions
Yugabyte's summit session on the questions a CISO asks (YouTube, on this page).
- LastPass breach
User data, billing information and vaults (Wikipedia).
- ISO 27001
For YugabyteDB, YugabyteDB Anywhere and the managed service (Yugabyte).
- Episode 31
Sergey on the show (Podbean, transcript).
- Detection tooling
How the security team chose a SIEM and SOAR tool (Yugabyte).
- CIS Benchmark
The first for a distributed SQL database, Yugabyte says (Yugabyte, LinkedIn).
- PCI DSS Level 1
- Episode 69
Riad Wahby on HSMs locked to enclaves (episode page).
- Episode 76
Michael Nov on security at the design stage (episode page).
- Meko
A data layer for multi-agent systems (Yugabyte).
- Episode 95
Pranava Adduri and George Gerchow on a sanctioned path to AI (episode page).
- KubeCon
Yugabyte at KubeCon + CloudNativeCon North America (X).
What to do this week
Five things, in the order of the episode.
- Name the unknown. The next time security says no, write down what it doesn’t understand yet, and set a time to work it out, as in A no means we don’t understand yet.
- Write down the intent. Pick three controls, note what each one protects against, and check whether your stack can meet that intent better, as in Reinterpret the control.
- Time the first hour. Pick a vendor or library you depend on, and time how long it takes to answer whether a breach there affects you, as in The hardest days.
- Publish your answers. Put your certifications and standard security documents on one page, so a questionnaire takes less time, as in Questionnaires from another era.
- Get help with it. Our vCISO Services turn controls into decisions engineering can live with, FedRAMP Readiness takes on the framework Sergey ranked first, and 24/7 Monitoring & Response covers detection and response. If you want to talk it through, book 15 minutes with us.