Research
Modern enterprise applications often consist of dozens of interconnected services, development environments, and staging servers. When these non-production environments are exposed to the internet, they can become a silent liability. In this write-up, we detail how our Continuous Attack Surface Management (CASM) product discovered an exposed staging environment
product
Most companies today use multiple security tools to detect vulnerabilities. Findings come from infrastructure scanners, SAST platforms, cloud security tools, container security platforms, and external attack surface monitoring solutions. The real challenge starts after detection. Vulnerabilities become scattered across different dashboards, ticketing systems, spreadsheets, and workflows. Every tool follows its
product
The Common Vulnerability Scoring System (CVSS) is widely used to assign severity to vulnerabilities, but it is not designed to function as a prioritization mechanism. Its primary purpose is to provide a standardized way to describe vulnerabilities based on exploitability and impact using a generic scoring model. This model assumes
Research
SAMA’s Cyber Security Framework enforces disciplined control across asset management, access control, vulnerability management, and continuous monitoring. It assumes that organizations maintain complete visibility of their assets, assign clear ownership, and enforce controls consistently across the environment. In structured environments, this model works. In modern environments, it breaks. Compliance
Research
SAMA’s Cyber Security Framework is a risk-based control model that enforces asset management, vulnerability management, and continuous monitoring across regulated institutions. It requires organizations to identify all information assets, assess their risk, and apply security controls through defined processes and remediation timelines. In theory, this creates a complete
appsec
SAMA’s Cyber Security Framework treats asset inventory as a foundational control. Organizations are expected to maintain an accurate inventory of assets, track configuration items, and understand how systems relate to each other. The logic is simple: if you don’t know what you own, you can’t secure it.
Research
Another expedition at Snapsec led us to Zendesk as our next target. The platform aligned well with our testing criteria, as its scope was extensive, the application surface was large, and the security team had a strong reputation for engaging constructively with researchers. With minimal scope restrictions and a feature-
It stars as a normal day. The ops lead had meetings, the coffee was lukewarm, and the ticket queue kept growing. “We’ll take it next week,” someone said. Next week became next month. Then, the breach call came. That’s the story repeated across industries: a small operational delay,
Back in March 2020 shuffling our private invites stock to crash into a program worthy of our time and excitement. In a while, we stumbled upon a program by name of Lark Technologies. Larksuite is a collaborrative platform where users can collaborate on various tasks. This product comprised of various
Modernizing Your Application Security
1. What Are Supply Chain Attacks? Imagine you’re building a house. Instead of breaking into your finished house, a thief sneaks into the factory that makes your bricks or nails and swaps them for defective (or booby-trapped) ones. When you build with those “trusted” materials, your house gets
SAMA sets strict regulatory expectations through frameworks like its Cyber Security Framework, requiring organizations to maintain full visibility of assets, continuously manage vulnerabilities, and enforce clear remediation timelines. The approach is structured, risk-driven, and heavily focused on accountability at every level. Organizations are expected to do a few key
Most organizations conduct security reviews on a schedule. Quarterly audits. Annual penetration tests. Periodic vulnerability scans. On paper, this creates the appearance of a well-governed security program. In reality, the attack surface does not follow review cycles. New infrastructure is deployed daily. Subdomains are created during product launches. Cloud
For years, penetration testing has been treated as a milestone rather than a capability. Organizations schedule a test, receive a report, remediate a subset of findings, and move on, often for another six or twelve months. On paper, this satisfies compliance requirements and gives leadership a sense of assurance. In
In modern enterprises, asset growth outpaces visibility. Infrastructure expands across multiple cloud providers, DNS zones multiply, APIs are deployed rapidly, and acquisitions introduce entirely new technology stacks. While security teams invest heavily in vulnerability detection, many organizations still depend on static asset inventories to define their security scope. Manual inventories
Modern security programs don’t fail because of missing scanners. They fail because of fragmented visibility. Domains live in one tool.APIs in another.IP ranges in spreadsheets.Certificates in someone’s inbox.Repositories in DevOps.Cloud buckets in yet another dashboard. Security teams think they have visibility. In reality,
In modern enterprises, vulnerability detection is no longer the bottleneck. With tools like Qualys, Nessus, Burp Suite, and Trivy, organizations generate thousands of findings daily across infrastructure, applications, containers, and cloud workloads. To manage this volume, security teams define SLAs: * Critical → 7 days * High → 14 days * Medium → 30 days On
For years, penetration testing has been treated as the ultimate proof of security maturity. Schedule a test, receive a report, fix the findings, and repeat the cycle next quarter or next year. On paper, this model appears rigorous. In practice, it no longer aligns with how infrastructure is built, changed,
The rapid rise of agentic AI systems has introduced a new class of security risk that sits uncomfortably between traditional malware, automation tooling, and cloud control planes. Clawdbot has become a useful reference point in this discussion—not because it is uniquely insecure, but because it reflects the broader security
Most organizations believe they understand their own infrastructure. They know their production environments, their internal networks, their approved services, and their deployed applications. Architecture diagrams exist. Asset lists exist. Ownership is documented-at least internally. Attackers see none of that. They do not start with your org chart, your CMDB,
Most organizations believe they understand their security posture because their internal controls are strong. Firewalls regulate traffic, EDR monitors endpoints, SIEM correlates logs, and IAM governs identities. Inside the perimeter, visibility is high and response is mature. Yet breaches increasingly begin before any of those tools see activity. The reason
As large language models move deeper into productivity workflows, a subtle but dangerous shift is taking place. AI systems are no longer confined to chat interfaces or passive assistance. They are becoming orchestrators of data, capable of reading, summarizing, writing, and triggering actions across tightly integrated enterprise services. That power