The State of Solana Security

Only ~17% are actively applying comprehensive logging and alerting controls. The majority of assessed protocols entirely lack centralized logging and alerting. They do not actively monitor for anomalous patterns on-chain or off-chain, and invariants are not accounted for in security measures.

Without real-time alerting, an active exploit can go unnoticed for hours or days. The inability to detect malicious behavior means attackers can systematically drain protocol liquidity without automated circuit breakers intervening or waking developers. By the time the team realizes an attack is occurring, the funds are already irreversibly lost. This is not limited to on-chain activity. The lack of logging and alerting in traditional environments, whether developer laptops, the infrastructure running off-chain resources, or SaaS products, all become blind spots in the staging of on-chain attacks.

Only ~13% demonstrate mature operational security practices. The standard observed is unmanaged devices, which co-mingle personal attack surfaces with protocol development or signing environments. Developers often have broad-reaching, unchecked access to the entire development and production infrastructure pipeline. Beyond this, the ability to move funds or adjust key program parameters is often protected by a single key, which in some cases is even stored directly on disk.

Exploitation of a contributor endpoint can lead to compromised deployer keys, admin credentials, cloud access, CI/CD privileges, or access to signing workflows, enabling tampering with deployments, frontends, dependencies, or operational infrastructure. Because many environments lack endpoint hardening, access segmentation, and robust key management, a single compromised device may enable lateral movement across development, production, and signing systems. When critical protocol actions are protected by single keys or keys stored on disk, this can lead to unauthorized upgrades, parameter manipulation, fund transfers, service disruptions, or a complete protocol takeover.

Only ~13% use verifiable builds throughout their development and production pipelines, or take measures to prevent resource manipulation along the way. The lack of provenance goes beyond dependencies to artifacts constructed and utilized throughout development and operational environments. There are also frequent opportunities for a single actor to bypass intended security constraints.

A compromised dependency during the build process can infect the protocol's core binaries before they are even deployed. The ability for a threat actor to utilize compromised credentials to not only push malicious code into a main branch, but also to circumvent controls put in place to prevent this by virtue of broad administrative access can lead to end-to-end compromise. Where strong controls exist to protect the development pipeline, a lack of provenance for builds and enforcement when using artifacts in production might lead to the direct injection of malicious code.

Only ~17% of protocols include advanced IR capabilities that plan for unexpected outcomes, despite the overall lack of known exploitable bugs. There is frequently a lack of both on-chain and off-chain circuit breaker implementations with diverse coverage to include invariant violation. The built-in capability to respond to security events in an isolated manner is also rare, with most implementations relying on a single-protocol kill switch that is manually activated.

Traditional code review looks for the capability to exploit a protocol for its funds, which provides a good layer of security. However, you should also design your program so that if that security fails, protective actions come into play. Assuming that an impossible outcome cannot happen while failing to create a response function for when it does leaves you defenseless when an attacker achieves the unthinkable. While establishing a comprehensive set of protective scenarios is essential, failure to isolate these defenses to specific functions or capital pools can exacerbate the fallout from an exploit. A truly resilient response relies on the ability to compartmentalize risk and integrate multiple defensive factors to limit the overall impact on users.