Sandesh Mysore Anand had a reasonable argument against drawing another diagram. He had helped produce a careful one while leading application security at a fintech company: a map of a complex system, complete with assets, boundaries and controls. A senior architect admired the work. Then he asked what anyone was supposed to do with it.
The architect had another objection. The underlying platform changed so quickly that the diagram could be obsolete within a day. Sandesh thought that was a touch theatrical; perhaps it would last a week. Either way, the drawing had a shorter shelf life than its creators might have liked. The security team had made something accurate, educational and expensive to maintain.
That exchange stayed with him. Roughly eighteen months later, he helped start Seezo, a company built around getting security advice into software plans before implementation. Large language models offered a tempting shortcut: read the documents, understand the system, produce requirements. Skip the compulsory drawing exercise.
By March 2026, Seezo was generating diagrams. Sandesh had listened to around a hundred customer conversations and reconsidered the product. The people using it needed a picture they could inspect, question and correct. The machine could live without one. Its colleagues could not always do the same.
The question that survived the meeting
This is a useful place to begin with Sandesh, now Seezo’s co-founder and CEO. His career has involved asking whether security work actually helps the people receiving it. An elegant assessment can satisfy its author while leaving an engineer wondering which task belongs in tomorrow’s sprint. The architect’s question was awkward because it was practical.
Sandesh’s route to that meeting ran through computer science and consulting. He studied engineering at Visvesvaraya Technological University from 2003 to 2007, then completed a computer science master’s at George Washington University in 2008-2009. In 2014, he added a public policy course at the Takshashila Institution. His education crossed technical systems and the rules people use to organize them.
He spent more than nine years at Cigital and Synopsys, helping companies develop their security programs. When he left in 2020, his farewell reflected on work across countries and the mentors and colleagues he had met. The achievement he chose to describe was a long apprenticeship with other people, rather than a tidy list of personal victories.
At Razorpay, he moved into the operator’s chair. He worked as a staff security engineer and subsequently in information security leadership. Advising a company and running its security work bring different pressures. The operator inherits the queue, the competing priorities and the task of making a sensible process survive contact with a busy engineering team.
A public commitment to being boring
Sandesh began writing Boring AppSec in 2021. The name establishes an unusual contract with a reader. In a field that can make a routine software defect sound like the opening scene of a disaster film, he offered attention to the work between the headlines. Inventories. Reviews. Requirements. The things that still need doing after the conference lanyards have been put away.
The title also leaves room for a joke. His essay about diagramming opens with a robotic Shakespeare facing the question of whether to draw. An earlier discussion of web application firewalls borrowed the same playwright for its title. Serious security work, in his writing, does not require a permanent expression of grave concern.
In March 2024, after twenty-five newsletter editions, he and Anshuman Bhartiya launched the Boring AppSec Podcast. Their first subject was software asset inventory. They wanted to take an apparently ordinary topic and examine it closely, supplying detailed notes so listeners could follow the references. Sandesh had already spoken on inventory automation with Razorpay colleague Satyaki Sanyal.
The conversation grew beyond a newsletter and a recording schedule. In 2026, Boring AppSec brought together two blogs, the podcast and a Slack community, with Chaithra M J helping run the operation. Bhartiya described the podcast as an idea they initially tried without planning its eventual shape. Thirty-one episodes later, there were people asking to keep the conversation going.
“Automate manual workflows, not humans.”Sandesh Mysore Anand and Rakshitha R Rao, their founding principles
The company inside the complaints
Seezo began in 2023 with Rakshitha Rao as his co-founder. Her experience included security consulting and customer success at CloudSEK and PingSafe. His included advising security programs and then operating one. Their shared starting point was familiar work that remained difficult to scale: understanding a proposed system and deciding which security requirements belonged in its design.
Sandesh found that even the name of this activity could derail a conversation. Seezo initially called its product Seezo TM. He later recalled that too much demo time went into arguments about whether the product counted as threat modeling. They renamed it Seezo SDR, for security design review. Sometimes the most productive technical decision is to retire a debate.
His conversations also uncovered a naming problem at the customer’s end. Teams that did not think they needed security design reviews nevertheless recognized the work under other labels: internal reviews, risk assessments or change management. The work existed; the vocabulary varied. A product could understand the task and still struggle to introduce itself.
By May 2025, he had spoken with more than a hundred security teams over the preceding twelve to fifteen months. Those discussions pushed him to think about security as part of how organizations manage change. Who approves a new system? Who supplies requirements? Who gets blocked? Culture could determine the answer as much as a technical standard.
- 01 / Read the planDocuments, tickets, diagrams
- 02 / Find the systemComponents, assets, data flows
- 03 / Ask what mattersRequirements tied to components
- 04 / Make a decisionInspect, challenge, act
Conceptual illustration of the review workflow. No performance measurements.
A dinner, a round, a longer conversation
Prayank Swaroop first met Sandesh at an Accel dinner for security leaders. The setting fits the story: a practitioner gathering, followed by discussions about a problem the founders had lived with. Sandesh later described more than two years of conversations with Swaroop as Seezo moved from an idea to a working company.
In October 2025, Seezo announced a $7 million seed round led by Accel, with participation from Transpose, Trenches, Ahead VC and MyAsia VC, alongside angel investors. The founders said the product had reached thousands of users around the world, including paying customers. The investment gave their plan resources; it did not relieve them of having to keep learning.
Their founding principles left room for customer judgment. Security teams should be able to choose how much to automate and where to require a person’s decision. A bank with a large security organization and a startup where the CTO handles security would need different arrangements. The company’s ambition was to serve both without prescribing an identical process.
The picture earns its place
The diagram’s return involved a wider engineering change. Seezo had paying customers and a stable platform, yet the team rebuilt its architecture. Earlier analysis could identify individual services and databases, but Sandesh wanted that understanding to be consistent. A useful answer about encryption should point to the particular database under discussion.
The revised approach identified components, assets and data flows before asking security questions. From that shared model, the product could generate both requirements and a visual map. It gave a reviewer somewhere to point when the system had misunderstood a relationship. Agreement became less important than having enough detail to disagree usefully.
The distinction resolved the old frustration. A diagram demanded before any review could become another obstacle. A diagram produced from the analysis could help someone check the work. Sandesh’s earlier objection had been to the cost and compulsory sequence; customer feedback revealed another purpose for the picture.
His March 2026 account also described future goals: connecting analysis to code and accumulating architectural context across assessments in an environment called Spaces. Those were ambitions built on the component model. He was trying to make the next review benefit from what the organization had already learned, instead of treating every document as a fresh introduction.
Leaving room for the person
Sandesh has another way of describing the changing security role. Drawing on Alison Gopnik’s parenting framework, he compares direct construction with tending a garden. He and his partner had encountered the idea while reading about parenting. He later applied it to security engineers who increasingly set conditions, supply context and supervise automated work.
The analogy makes a demanding job sound deceptively restful. Somebody still has to decide when tools run, what internal standards they should know and which results need attention. A garden supplies plenty of work for anyone imagining retirement. Sandesh’s point is that expertise moves into shaping the environment as more assessment work becomes automated.
Away from work, his Nullcon speaker biography lists birding, running, food and following several sports teams. The range is pleasantly incompatible with the newsletter’s promise of boredom. These are small details, but they give the public security professional a life beyond software queues and architecture documents.
The central question in his work remains recognizably human: what can the person receiving this analysis do next? An architect asked it before Seezo existed. Customers asked versions of it as the product grew. Sandesh has built a company, a newsletter and a continuing conversation around getting closer to an answer. In the process, he found himself drawing the picture again.