Under the Hood: Mysten Labs’ Strategies for Building the Most Secure Blockchain
How Mysten Labs builds secure and low-friction systems for blockchain by focusing on code ownership, usability, and AppSec strategy.
How Mysten Labs builds secure and low-friction systems for blockchain by focusing on code ownership, usability, and AppSec strategy.
How Mysten Labs builds secure and low-friction systems for blockchain by focusing on code ownership, usability, and AppSec strategy.
%20(1).png)
How Mysten Labs builds secure and low-friction systems for blockchain by focusing on code ownership, usability, and AppSec strategy.
How Mysten Labs builds secure and low-friction systems for blockchain by focusing on code ownership, usability, and AppSec strategy.
Hi, I'm the Head of Software and Infrastructure Security at Mysten Labs. My role involves a combination of designing, building, integrating, and strategizing to create an entire security ecosystem that spans from how developers write code to how we ship a product.
At Mysten Labs, we're deeply involved in the research and development side of building foundational technology for ecosystems. As original contributors to Sui and Walrus, our work forms the engineering backbone for tier-one blockchains, including the complex software that runs validating nodes and virtual machines for crypto wallets and smart contracts.
When it comes to measuring the product security program’s success, the ultimate metric is simple: "How many times have we been hacked in the last 90 days?" This is the difference between holding the frying pan and being in it. Beyond that stark reality, I view metrics less about daily numbers and more about change over time. Improvement is measured by the effectiveness of our strategies.
Strategy #1: Be the most secure blockchain company
Our team’s biggest priority, one that is fundamental and ongoing, is our commitment to helping build and maintain the most secure blockchain in the world. This isn't just a technical goal; it's a critical business advantage. In any blockchain or tier-one ecosystem, user faith is paramount. Nobody will participate if they fear losing their assets overnight. Guaranteeing the security of the software, the dependencies, and the business processes themselves is a monumental, data-oriented problem.
To achieve that, we absolutely need to be the most secure blockchain company, which means having the most secure processes and methodologies in place. Other product security priorities are derived from this overarching company goal. Ultimately, my measure of success or failure is whether I keep us focused on our mission to be the most secure tier one blockchain.
Strategy #2: Make security usable and low-friction for engineering
Mysten Labs is a deeply engineering-first organization, and we hire senior people who remain hands-on. With an experienced team and a company mandate for secure products, everyone tends to inherently act as security champions. This reduces the need for a formal championship program, although I believe they are incredibly important in organizations with more junior developers.
However, that does not mean we can allow for poor security experiences! A cornerstone of our strategy is to ensure that security doesn't become a roadblock. My team and I spend a vast majority of our time making products secure without making the lives of our engineering organization miserable. At all times, the most secure way to do something must also be the easiest way. If security controls are difficult to use, people will inevitably find workarounds, which undermines the entire effort. We place heavy emphasis on smoothing processes and making security intuitive.
Dogfooding security tools and processes
I don't believe satisfaction surveys accurately capture developer happiness or workflow friction. That’s why we rely heavily on dogfooding to measure whether we’re being engineering-friendly. If the product security team wouldn’t be willing to use a tool or live within a process ourselves, then we can't expect it to be good for software developers. And before you suggest using test applications, we’ve found them to be insufficient because they’ll never act like our infrastructure monorepo that has a 10-hour build time!
We dogfood application security (AppSec) tools and processes by writing code, building applications and infrastructure, and experiencing firsthand what it's like to use the security tooling we implement. This process reveals problems like being unable to block PRs because scans that take too long. This practical flow is crucial for identifying friction points (like long scan times on large monorepos) which require innovative solutions like incremental builds. Very often, I find I'm doing something I thought was a good idea and realize, "wait, this is really annoying", which often leads to figuring out a different way that's easier and more secure.
Critical AppSec skills
Our dogfooding practice ties directly into the kind of security talent we value. Like other leaders at tech-forward companies, I strongly believe that security engineering requires software development skills. You need both the security mindset (the paranoia, the focus on finding vulnerabilities) and the software development understanding to truly grasp the "aha" moments of where security issues can arise and how to build things securely. While you don't need years of prior development experience to be a good AppSec engineer, you absolutely need to be writing software and working directly with development teams.
Strategy #3: Improve security and engineering efficiency
Beyond just patching vulnerabilities, success is measured by the effectiveness of strategies towards implementing the software itself. Developing these strategies involves understanding exactly what's inside our product, including dependencies. One area we focus on is reducing technical debt and supply chain risk by decreasing our total number of dependencies. We look for libraries that are only used for one or two functions and aim to replace them with minimal internal code, effectively removing the entire dependency. This not only reduces the potential attack surface and supply chain issues but also aligns with building more efficient, ownable codebases. Owning every line of code entirely is the most secure approach.
This approach isn't just about reducing potential vulnerabilities and fixing supply chain issues; it makes the product more secure by owning code where possible. Achieving code ownership in this manner requires tools that provide accuracy of data, contextualized findings, and reliability, especially given the complexity of our build systems. Being able to rely on the data allows us to rapidly block the most critical issues within the development workflow without adding tremendous manual work for the team. (More on this below.)
Where AppSec tools fit into our strategies
An application security tool isn't just a box to tick; it can be a critical enabler of our security strategies, or it can become a significant roadblock. For me, the effectiveness of these tools is directly tied to their ability to help us achieve our strategies. In fact, we recently switched vendors because our previous platform for SCA, SAST, and secrets had become a major blocker.
Positive impacts (from an effective tool)
- Accurate and actionable insights: Provides reliable, contextual data about what's inside the product, including complex dependency trees and code usage.
- Enhanced developer experience: Creates a low-friction workflow with fast scan times integrated into CI/CD, delivering actionable findings like reachability.
- Supports foundational security & efficiency: Enables a deeper understanding and management of dependencies, helping identify underused code.
- Enables strategic control & long-term value: Allows for powerful, uniform policy creation across the codebase and enables strategic blocking of critical issues like malware, secrets, or severe vulnerabilities within the workflow.
Negative impacts (from an ineffective tool)
- Inability to trust findings: Our previous tool had a high false positive rate and couldn’t reliably determine whether code was being used in production. For example, it flagged vulnerabilities in outdated dependencies or test binaries that weren’t actually built or shipped.
- Lack of actionable data: Engineers need contextualized findings to prioritize remediation (such as knowing if a vulnerability is reachable) but the tool’s technical limitations prevented it from providing this level of detail. It also didn’t support reachability analysis for transitive dependencies, which is problematic since that’s where the majority of vulnerabilities are discovered.
An effective AppSec tool doesn't just identify problems; it integrates into the engineering process, provides reliable, actionable data, and supports our strategic goals of building the most secure systems efficiently and with minimal friction.
About Mysten Labs
Founded in 2021, Mysten Labs is a research and deployment lab forging the path to uplift and advance a better internet. As the original contributors to the Sui Layer 1 blockchain, Mysten Labs is a pioneer of equitable decentralized technology, redefining the capabilities of blockchain via Move, the programming language created by Mysten Labs CTO Sam Blackshear. Mysten Labs also designs open-source products that make building on and interacting with Sui easier.
About the Author
Paul Padilla is the Head of Software and Infrastructure Security at Mysten Labs, working within the product engineering function. His background is primarily in security, starting in forensics and moving into offensive and software security disciplines like pentesting, red teaming, malware deployment to prove security, and software analysis techniques. He views this progression as “learning to hack at scale”.
