Prime Resources
featured articles
Cutting Through ProdSec Noise
Prioritizing Vulnerabilities by Context Driven Attack Paths, Not Severity Score
Open any vulnerability dashboard right now and you'll see the same thing every security team sees: more findings than anyone could review in a lifetime, ranked by severity scores that all cluster near the top. Roughly 48,000 new CVEs were published in 2025 alone, and the average program has bandwidth to remediate somewhere between 10 and 15 percent of its backlog in a given month. That gap between what gets found and what gets fixed isn't a staffing problem. It's noise, and it's been mistaken for a risk picture for long enough that most teams have stopped questioning it.
Vendors have started layering exploitability and reachability signals on top of severity scores, flagging whether a CVE has a known exploit in the wild or whether the vulnerable function is actually called by application code. That's a real step past CVSS alone, and it does cut some findings out of the queue. But exploitability and reachability answer "can this be exploited," not "does it matter here." A reachable, exploitable vulnerability in an internal tool with no sensitive data behind it is a different risk than the identical vulnerability in a service with a direct path to payment data, and exploitability scoring alone can't tell those two apart. Without the business and architectural context to make that distinction, exploitability and reachability data just re-sorts the same pile into a slightly different order. It doesn't reduce it.
Where All This Noise Comes From
Noise doesn't come from one bad scanner. It comes from the fact that every scanner you add reports its own findings in isolation, with no view of whether anything it flags actually connects to anything else. SAST grades code. SCA grades dependencies. Secret scanning grades commits. Each one is doing its job correctly, and each one is contributing its own independent stream of severity-ranked findings to a backlog that was already too large before it showed up.
That fragmentation was survivable when code shipped at human pace. AI coding agents have removed that constraint, and the backlog is growing with it. A developer opens a handful of pull requests a day; an agent working in the background can open dozens, and every one of them triggers its own pass from every scanner in the pipeline. The noise problem stopped being something a team could plan around once a quarter and became something that compounds with every commit an agent makes, which means the case for reducing it is no longer theoretical. It's urgent, and it gets more urgent by the day.
Adding tools to cover more of the stack feels like progress, and in a narrow sense it is. But it also means the noise compounds. Four scanners each reporting cleanly on their own slice of the product doesn't add up to a quieter picture of risk. It adds up to four separate streams of findings, none of which know about the other three, and that isolation is exactly what produces false positives and false confidence in the same breath. A scanner with no view of the environment has no way to know a downstream control already neutralizes what it just flagged, so it reports a real finding as urgent when it isn't. The opposite failure is just as common: without understanding how the surrounding system actually behaves, a tool can't verify whether a vulnerability it found is reachable in an actual attack path, which means genuine risk gets buried in the same pile as the noise around it.
Why More Noise Doesn't Mean More Security
The instinct is to sort the noise by severity and work top-down. That fails because severity measures how bad a vulnerability could theoretically be, not whether it's reachable, exposed, or exploitable in this specific environment. Two findings with identical CVSS scores can carry completely different risk depending on what's around them: one sits behind three layers of controls, the other has a direct path to production. A backlog sorted by severity alone treats those as the same problem, which is exactly why teams burn remediation capacity on findings that were never going anywhere while genuinely dangerous ones sit untouched further down the list.
Cutting Through the Noise Starts with One Question
Cutting through that noise isn't a matter of triaging faster or tuning the scoring model harder. It requires asking a different question of every finding, one severity scores were never built to answer: is this part of a path an attacker could actually walk right now, given what it connects to. And more importantly, how feasible is this path? If an exploit requires Tom Cruise to dangle dramatically from the ceiling, it’s unlikely to be prioritized by attackers. In other words, there is no simple solution that relies on a single score…which is exactly why context matters!
That's an execution-path question, not a severity question, and it changes what "important" means. A CVSS 9.8 sitting on a service with no route to anything sensitive isn't urgent, whatever the score says. A medium-severity finding sitting on a component that connects straight to a trust boundary might be the most important thing in the backlog. Severity describes a finding in isolation. An execution path describes what happens once you stop looking at scores and start focusing on the real impact to the business and how exposed the vertical to that impact.
What's Left When You Filter for Execution Paths
Run that filter honestly and the backlog doesn't just get shorter, it changes shape entirely. What's left isn't a smaller version of the same list sorted the same way. It's a small, specific set of findings that are reachable and chained together into something an attacker could actually use, the kind of path where a component that passes its own scan cleanly still turns out to be one link in a route to something that matters.
Building a Practice Around Signal, Not Volume
None of this is an argument for buying another scanner. Another scanner adds another stream of severity-ranked findings, which is exactly the problem, not the fix. What's needed is something that doesn't produce its own isolated list at all: a way of seeing the product as one connected system, where a finding is judged by what it opens up rather than scored and filed on its own.
SAST, SCA, and secret scanning were built to grade their own slice of the product well, not to reason across slices, and no amount of tuning changes that. What's missing is a layer above all of them, one that holds architecture, data flows, and access paths in view together and asks the question none of the individual scanners can: does this finding sit on a path an attacker could really walk, given everything else true about this product right now.
The Elephant in the Room: Developer Alert Fatigue
The noise problem doesn't stay in security's backlog. Every finding that reaches a developer without context asks them to stop and chase down whether it's real, and often it isn't: a downstream control already handles it, the path doesn't exist, the function isn't even called. After enough of those empty chases, the rational response isn't more diligence. It's discounting the next finding, and the one after that.
That erosion is the real cost. It isn't just inefficient for security teams triaging a backlog. It teaches developers, correctly, that most of what lands in their queue isn't worth their time, which means the findings that actually matter now have to fight through that learned skepticism to get acted on at all. The fix isn't more findings or sterner tickets. It's surfacing only what's already been checked against the path it would need to travel.
What This Means for Security Leaders
The measure of a good vulnerability management practice was never how many findings you closed this quarter. It's whether what's left in front of your team, after the noise is filtered out, is actually worth their time. A shorter list sorted by the same broken signal isn't progress. A list built from real execution paths, however short, is.
At Prime, this is the case for correlating findings against real execution paths across the whole product rather than triaging them one severity score at a time, so what reaches your team is what an attacker could actually walk, not everything a scanner happened to flag.
Ready to see what's left once the noise is filtered out? Learn more at primesec.ai.
Software Security Needs a New Unit to Review
For the last decade, the pull request has been the moment a developer's work paused long enough for someone else to look at it. That pause is what turned the PR into a checkpoint. A reviewer read the diff and checked it for whatever could go wrong: bugs, broken business logic, security holes. Nobody designed the PR to be a security control. It became one because it was the last place in the software lifecycle where a person reliably paid attention before code shipped.
Now agentic development is breaking the math that made the diff work. PRs are getting bigger and more frequent at the same time, and the pause they run through hasn't gotten any longer. The unit of review is shifting under security's feet.
Before anyone scanned PRs, security tools ran against whole repositories, and compliance programs accepted that as review. The results were unusable: thousands of noisy findings and no way to tell which ones mattered. So the industry moved down to the diff. It was the easiest unit to work with, not the right one.
The PR is changing. Drastically.
Look at what a pull request is actually made of: a diff, a comment thread, and an approval button. None of it was ever the control. It was just tooling built for the moment someone paused to review the work. The pause survived on three conditions. PRs stayed small enough to read closely. Rare enough that every one of them got read. And the review produced a handful of issues that a developer will actually fix.
Agentic development is killing all three at once. Cursor's enterprise data shows average PR size more than doubling, with volume up another 25% on top. Mega PRs, 1,000 lines or more, are now routine. A Microsoft study of Claude Code and GitHub Copilot CLI users found adopters merging roughly 24% more PRs, hitting 50% in heavy-use weeks and holding there for four months. And bigger PRs carry more issues per review, pushing every comment thread past the point where developers stop reading it.
Any one of these would strain a review built around a careful pause. Together they take away everything it needed: time per PR, few enough PRs to give each one that time, and findings scarce enough to get fixed.
What's actually inside all those new PRs
Volume is only half the problem. The other half is what's landing inside each PR. CodeRabbit's analysis of AI-co-authored pull requests found they carry roughly 1.7 times more issues than human-only PRs, including 1.5 to 2 times more security-relevant findings like improper credential handling and insecure object references. High-issue outliers cluster in AI-assisted work. So a reviewer doesn't know which PR needed the slow read until they've already skimmed past it.
Compliance programs accept PR approvals as evidence that changes were reviewed before deployment. Today, the audit trail looks exactly like it did three years ago. What's changed is what that approval means. It used to mean someone read the code. Now, on a 1,500-line agent-written PR that arrived with six others that morning, it mostly means the person ran out of reasons to keep it open. The requirement is still being met on paper. Whether real security is happening underneath is a separate question, and no audit is built to ask it.
The unit was always a proxy
Once you see the PR as a stand-in for attention rather than a control in its own right, the question changes. Scaling review to handle more, bigger PRs is the wrong project. The real question is where that attention needs to live now that it can't all sit in one checkpoint.
Some of it belongs below the PR, where an agent makes decisions in real time and context can be applied before a diff exists. Some belongs above it, at the repository level, because a vulnerability spread across several small, reasonable PRs never shows up in any single diff. And some belongs before the PR entirely, in the architecture and design decisions that shape what an agent, or a developer, can build in the first place.
The repository level is the one that should give people pause, because the industry has been there before. Repo-wide analysis is where this story started, and it collapsed under its own findings. But that was a context problem, not a level problem. The tools flagged patterns without knowing what was reachable, what was exploitable, or what mattered to the product. Analysis that traces attack vectors and validates exploitability before it surfaces anything produces the one thing the old scanners never could: a short list. Five findings a developer will actually fix, with a risk score that is attached to a product. The comment-count condition, restored at the level the industry abandoned.
So PR reviews are dead? Right? Right?
No, PR reviews aren't dead. The pause they measured is.
Reviews stay in the program as one place security happens, not the primary one. Attention has to live where decisions live now: in the design before code exists, in the code as it's written, in the repository as it evolves. This is what we do at Prime, that's the architecture: review the design, guard the code, trace attack vectors across the repo, dependencies, and cloud continuously.
Black-Box Pentesting Gives Attackers the Advantage
For years, black-box penetration testing has relied on a simple premise: simulate an attacker who knows nothing about the system. The tester starts outside the application, discovers endpoints and functionality, infers architecture, and gradually builds an understanding of how the product works.
That assumption is outdated.
A serious attacker already has more information than the traditional black-box model assumes. Source code routinely leaves organizations through compromised insiders, contractors, repositories, legitimate access obtained under false pretenses, and AI-assisted development workflows. Source secrecy is no longer a strong foundation for offensive security.
If applications need to remain secure when an adversary understands how they work, testing needs to begin from the same vantage point. That is attacker parity.
Source code leaves through ordinary access
Source-code theft does not require a dramatic breach.
The North Korean IT worker campaign illustrates the problem. The FBI has warned that DPRK IT workers use false identities to obtain legitimate employment with U.S. companies and then use that access to steal proprietary information. In January 2025, the FBI specifically warned that workers had held stolen source code and other proprietary data for ransom.
Google Threat Intelligence has documented the same campaign at significant scale. The important security lesson is how access is obtained. An attacker hired under a false identity receives credentials, repository access, internal communications, and the same development environment as other employees. From the application's perspective, that access is legitimate.
AI-assisted development creates another path. Developers now work across coding assistants, model APIs, IDE extensions, autonomous agents, and third-party development services. When proprietary code is submitted to an external AI service, that service becomes part of the system trusted with the code. NIST's Generative AI Profile identifies data privacy, information security, third-party components, and data governance as areas organizations need to manage when deploying generative AI.
Source confidentiality is a weak assumption for an offensive security strategy.
Black-box testing assumes attacker ignorance
A black-box tester spends part of every engagement reconstructing information the engineering organization already possesses. They discover APIs, map routes, infer trust boundaries, experiment with authentication flows, and probe application behavior to understand the architecture.
That work is useful when the objective is to measure what an outsider discovers from an exposed application. It is a limited model of what a capable adversary does.
Source access changes the economics of attacking an application. Reconnaissance is faster, hypotheses are easier to form, and security controls are inspected directly instead of inferred through trial and error. Authorization logic, hidden endpoints, dependency behavior, and implementation assumptions all become easier to investigate.
The attacker spends more time searching for exploitable weaknesses while the black-box tester spends valuable engagement time rediscovering how the product works.
We already accept this model with open-source software. Security controls in an open-source application must withstand attackers who can inspect the implementation. Proprietary applications deserve the same standard.
White-box testing creates attacker parity
Defenders already possess an extraordinary amount of useful security context. They have the source code, architecture, security requirements, dependencies, deployment model, and historical design decisions.
White-box penetration testing puts that context to work.
A tester who understands the implementation moves directly into deeper questions about exploitability. They trace authorization logic across services, follow data through trust boundaries, examine how security controls are implemented, and identify places where implementation differs from design intent.
That context also makes it easier to investigate attack paths rather than isolated findings. A minor authorization weakness becomes critical when combined with a particular identity path or cloud configuration. Source code provides only part of that picture. Effective Product Security testing also needs architectural context, identity, infrastructure, dependencies, and application behavior.
A capable attacker uses whatever information they obtain. Defenders should use the information they already own.
Attacker parity must continue as the product changes
A white-box assessment still represents a point in time. The application starts changing again as soon as the engagement ends.
New code lands, dependencies change, APIs evolve, infrastructure is modified, and authorization logic gets refactored. AI coding tools and development agents have accelerated software production and increased the volume of changes security teams need to understand.
Attackers keep studying the product as it evolves. Offensive security needs the same continuity.
Continuous white-box pentesting preserves application context and repeatedly evaluates what is actually exploitable as the product changes. At Prime, that means connecting code with architecture, dependencies, cloud resources, application behavior, security decisions, and attack paths so testing starts with the context required to investigate meaningful risk.
Black-box testing still has a role
Black-box testing remains useful for understanding what an unauthenticated or opportunistic outsider discovers. It tests externally observable attack surface and exposes weaknesses in authentication, configuration, discovery, and application behavior.
It should not define the upper bound of an offensive security program.
A motivated adversary has source code, internal documentation, credentials, architecture details, or extensive time to study how the product works. Your security team already has more context than that.
Use it.
Treat source access as part of the threat model, give testers the information advantage available to defenders, and test applications from the perspective of an informed adversary.
Ready to see how Prime continuously tests applications with the same product context an informed attacker would? Learn more at primesec.ai.
Why We Should Talk More About Product Security
We all know the following fact: software development is in overdrive. Agile, DevOps, cloud-native platforms, microservices, code co-pilots, you name it, have made shipping products faster and easier than ever. But here’s the catch: all that speed and innovation has created a tangled mess of interconnected parts. And when it comes to security, most teams are still trying to tackle the problem one layer at a time:infrastructure here, application code there, data somewhere else.
And while this still covers main areas of concern, it also slows the business down. Modern software products are more like intricate ecosystems than neat stacks. If you’re only looking at security layer by layer, you’re missing the big picture, and leaving your product open to serious risk. Risk that is not confined to a single layer, but sprawls across all of them.
The Problem with a Lack of Business Context
Let’s take a page out of the great movie Big Short, and look at how restaurants operate. Say you just built a new top-of-the-line restaurant, hired the best chef, and ensured the dining area is off the charts! But if you don’t understand how your customers move through the restaurant, their favorite dishes, or what drives repeat visits, you will be working hard to make the business work but could be focusing on the wrong things. Put simply, you will be losing money.
The same is true for product security. Without understanding the broader business context, security teams can’t make truly risk-driven decisions. This often leaves them riding in the dark, with the occasional streetlamp to guide them. In cloud-native products, where everything moves fast and every decision matters, security must align with the product’s goals.
The Challenge with Manual Security Reviews
At this point we expect you to stop and say, “don’t we already have security reviews to handle this? Aren’t they supposed to catch every potential issue, ensuring that every change and development is seen through the proper lens of security?” Technically, you’d be right; that’s exactly what security reviews are meant to do. But we are realists and not hopeless optimists: the process is still manual. It relies heavily on human effort, tracking changes, analyzing risks, and trying to keep up with the relentless pace of development.
Now let me adjust the question a bit: how can we secure the business when development velocity has skyrocketed, business logic evolves constantly, and security is overwhelmed with vertical security and is constantly understaffed? The gap is growing wider by the day.Without automation, context-driven insights, and a holistic approach, security teams are left playing catch-up, reacting to risks after they’ve already been introduced instead of preventatively mitigating them. If we’re going to keep up, the way we approach security reviews has to evolve.
Why Security Needs to Evolve
The reality is security can’t afford to be stuck in the past. Software development has evolved into a high-speed race where new features and updates are shipped daily. The business logic driving these changes is constantly shifting, and manual security processes just can’t keep up.
To meet these demands, security needs to shift its mindset. It’s no longer about simply protecting individual layers or running manual reviews when something big is about to be released.It’s about building a security framework that understands the business context, moves at the speed of development, and sees the product as a dynamic, interconnected ecosystem. This means integrating automation, embracing a secure by design mindset, and embedding security into every aspect of the product lifecycle. Only by evolving in this way can security teams keep up with the pace of innovation while not only protecting the business, but also enabling it from the ground up.
Can we expect developers to be security experts?
Secure development is challenging and can be a significant drain on time and resources. Adding security responsibilities to developers’ workloads can overwhelm teams and raise security risks for organizations.
The pressure is on
Development is moving faster than ever, with AI accelerating the pace to new heights. Developers want to focus on what they do best, building and shipping great products. But when security tasks are layered on top, it creates a difficult trade-off, often sacrificing security for speed.
We recently met an impressive Product Security team at a fast-growing fintech company. They had all the right processes and tools, yet a critical design vulnerability, a broken authentication, slipped into production. Why? Developers had pushed for a low-risk classification for the release. The fallout: an unplanned emergency patch and a month of lost development time.
This isn’t an isolated story. Many organizations report similar experiences: development teams often label risks as “medium” or “low,” only for critical vulnerabilities to sneak into production, triggering fire drills and costly late fixes.
The data speaks for Itself
Accelerated development cycles - traditional automation and modern AI tools are speeding up development cycles. Great for innovation and velocity, but it also means that design risk increases if security guidance isn’t seamlessly integrated into the process
Growing complexity - with expanding tech stacks, developers need just-in-time guidance on integrating new technologies into their products and features.Code scanning alone can’t provide this support
Rising late remediations – despite the focus on secure development, the bug bounty and pen testing markets are expanding faster than ever, reflecting that vulnerabilities still slip through, demanding costly late fixes.
High developer turnover – developers change roles frequently, often staying for less than two years. By the time they’re trained on secure practices, they may move on, leaving knowledge gaps and disrupting the organization’s security continuity
Finding the real solution
Rather than expecting developers to shoulder security independently, organizations need to embed security directly into the development process - automated, integrated, and always present. This approach ensures developers receive consistent, reliable guidance without interrupting their workflow or slowing innovation.
Seamless integration of security into existing workflows allows developers to stay focused on what they do best, develop. With the right guidance, at the right time, they can make informed security decisions effortlessly.
At Prime, we make security guidance as seamless as your code deployments.
Our integrated approach ensures your team has the support they need, when they need it, for secure, rapid development. Ready to streamline security without slowing your development team down? Reach out to see how we can help.
Security by Design: Regulatory Requirements in October 2024
Building Secure Foundations: The Shift Towards Security by Design
“Security by Design” is no longer a best practice - it is a regulatory auditable imperative. Various global standards and frameworks now mandate that organizations adopt SbD principles to ensure compliance with data protection, privacy, and cybersecurity regulations.
Traditionally, security is reactive—addressed only after systems were developed or, worse, once a breach had already occurred. The limitations of this reactive approach have driven the emergence of the “Security by Design” philosophy, which prioritizes the integration of security measures right from the earliest stages of design and development. This principle has become a foundational aspect of the Software Development Lifecycle (SDLC), embedding security directly into the architecture of systems and products from the ground up.
Rather than relying solely on reactive methods like scanning run-time systems or identifying vulnerabilities after deployment, “Security by Design” focuses on preventing these risks much earlier in the process. It ensures that security considerations are a core element of the product development journey, reducing the likelihood of security flaws and minimizing the need for costly, time-consuming fixes later.
Regulators and international standards bodies have recognized the value of this approach. By incorporating “Security by Design” into the various frameworks, they are urging organizations to proactively identify potential security gaps and vulnerabilities, embedding robust security safeguards from the inception of any product or system. This shift towards a preemptive security strategy represents a significant evolution in how security is conceptualized and implemented across industries.
Relevance by Regulatory Framework
The table below outlines the “Security by Design” requirements within the current regulatory landscape and explains how organizations can achieve both procedural and technological compliance requirements with Prime Security.
NIST
The National Institute of Standards and Technology (NIST) is a U.S. government agency that develops and promotes measurement standards, technology, and science to enhance economic security and quality of life.
| Standard Name | Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|---|
| NIST CSF 2.0 | Platform Security (PR.PS) | PR.PS-06 Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle | Prime incorporates secure development practices during the design phase and automatically identifies security risks |
| CA-02(02) Control Assessments | Specialized Assessments | Specialized assessments can also be conducted early in the system development life cycle (e.g., during initial design, development, and unit testing). | Prime facilitates the early identification of security risks by conducting security assessments during the initial design stage of system development lifecycle | |
| SA-03 System Development Life Cycle | a. Acquire, develop, and manage the system using an organization-defined system development life cycle that incorporates information security and privacy considerations. | Prime incorporates security and privacy requirements into the organization's SDLC by identifying risks early in the design phase | |
| SA-03 System Development Life Cycle | d. Integrate the organizational information security and privacy risk management process into system development life cycle activities. | Prime embeds the organization's security and privacy engineering principles or industry best practices into the design phase of SDLC | |
| SA-08 Security and Privacy Engineering Principles | Apply the organization-defined systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components. | ||
| NIST 800-53r5 | SA-08 Security and Privacy Engineering Principles | Ensure that the systems security and privacy engineering principles are applied throughout the system development life cycle. | Prime embeds security and privacy requirements at the design stage, ensuring they are upheld throughout the SDLC |
| NIST 800-53r5 | PM-07 Enterprise Architecture | Integrate security and privacy requirements and controls into the enterprise architecture to ensure they are addressed throughout the system development life cycle and are explicitly related to the organization's mission and business processes. | Prime embeds security and privacy requirements at the design stage, ensuring they are upheld throughout the SDLC |
| NIST 800-53r5 | RA-08 Privacy Impact Assessments | Conduct privacy impact assessments for systems, programs, or other activities before developing or procuring information technology that processes personally identifiable information. | Prime identifies engineering tasks that could potential cause privacy violations prior to them being started |
ISO
The International Organization for Standardization (ISO) is a global body that develops and publishes international standards for products, services, and systems across various industries.
| Standard Name | Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|---|
| ISO/IEC 27001:2022(E) | 8.26 Application security requirements | Control: Information security requirements shall be identified, specified and approved when developing or acquiring applications. | Prime integrates into the organizational system development life cycle, detects and mitigates security gaps in the requirements given to systems and projects |
| ISO/IEC 27001:2022(E) | 5.8 Information security in project management | Control: Information security shall be integrated into project management. | Prime integrates information security into project management by embedding security requirements and risk assessments as early as possible in the development lifecycle |
| ISO/IEC 27002:2022(E) | 5.8 Information security in project management |
Control: Information security should be integrated into project management. Purpose: To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle. Guidance: Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes). The project management in use should require that:
Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. |
Prime integrates information security into project management by ensuring that security risks are assessed and treated early and periodically throughout the project lifecycle. It incorporates security requirements, such as application security and intellectual property compliance, from the planning and design stages, leading to more effective and cost-efficient solutions |
| ISO/IEC 27002:2022(E) | 8.25 Secure development life cycle |
Control: Rules for the secure development of software and systems should be established and applied. Purpose: To ensure information security is designed and implemented within the secure development life cycle of software and systems. Guidance:
|
Prime helps establish and apply rules for the secure development of software and systems by embedding information security requirements into the specification and design phases of the development lifecycle. This ensures that security is integrated from the outset, providing a foundation for building robust and secure applications |
| ISO/IEC 27002:2022(E) | 8.27 Secure system architecture and engineering principles |
Control: Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities. Purpose: To ensure information systems are securely designed, implemented and operated within the development life cycle. Guidance: Security engineering principles should be established, documented and applied to information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology). New technology should be analyzed for security risks and the design should be reviewed against known attack patterns. Secure engineering principles provide guidance on user authentication techniques, secure session control and data validation and sanitisation. Secure system engineering should involve:
|
Prime helps organizations establish, document, and maintain secure system engineering principles throughout the development lifecycle, ensuring security is integrated into all architecture layers—business, data, applications, and technology. It supports security-by-design practices, such as "defense in depth," "least privilege," and "default deny," while guiding security-oriented design reviews to identify vulnerabilities and ensure adequate controls are in place |
PCI-DSS v4.0
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements designed to ensure that all companies that process, store, or transmit credit card information maintain a secure environment.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| Requirement 6: Develop and Maintain Secure Systems and Software | 6.2.1: Incorporating consideration of information security issues during each stage of the software development lifecycle. | Prime incorporates information security considerations during the design stage of the software development lifecycle, ensuring that potential risks are identified and addressed early. This proactive approach reduces the likelihood of discovering security vulnerabilities at later stages, minimizing costly rework and enhancing overall system security |
HITRUST
The HiTRUST (Health Information Trust Alliance) CSF (Common Security Framework) is a comprehensive security framework designed specifically for the healthcare industry. It combines and harmonizes various standards and regulations, including HIPAA, PCI, and ISO, to provide organizations with a unified approach to managing information security and privacy risks in healthcare.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| Control Category: 10.0 - Information Systems Acquisition, Development, and Maintenance |
Control Objective: To ensure that security is an integral part of information systems. Control Specification: Statements of business requirements for new information systems (developed or purchased), or enhancements to existing information systems shall specify the requirements for security controls. Specifications for the security control requirements include security controls to be incorporated in the information system, and supplemented by manual controls as needed. Further, security control requirements are considered when evaluating software packages, either developed or purchased. |
Prime ensures that security is an integral part of information systems by embedding security control requirements into the specifications for new or enhanced systems. This approach ensures that security requirements are considered from the outset |
CSA controls matrix v4.0.12
The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) is a cybersecurity control framework specifically designed for cloud computing environments. It provides a comprehensive set of cloud-specific security controls to help organizations assess and improve their cloud security posture, align with various regulations, and enhance overall risk management in cloud deployments.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| Application & Interface Security Secure Application Design and Development (AIS-04) | Define and implement a SDLC process for application design, development, deployment, and operation in accordance with security requirements defined by the organization. | Prime integrates the organization's security requirements into the SDLC by identifying risks and defining security controls during the application design phase |
| Data Security and Privacy Lifecycle Management Data Protection by Design and Default (DSP-07) |
Develop systems, products, and business practices based upon a principle of security by design and industry best practices. | Prime enables the development of systems, products, and business practices based on the principle of security by design and aligned with industry best practices. It incorporates security requirements from the outset, ensuring that security is embedded throughout the development process |
| Data Security and Privacy Lifecycle Management Data Privacy by Design and Default (DSP-08) |
Develop systems, products, and business practices based upon a principle of privacy by design and industry best practices. Ensure that systems' privacy settings are configured by default, according to all applicable laws and regulations. | Prime automatically identifies potential privacy violations during the design stage, ensuring that privacy requirements are integrated from the outset. It helps configure systems' privacy settings by default to comply with applicable laws and regulations, following the principle of privacy by design and industry best practices |
COBIT 5
Control Objectives for Information and Related Technologies (COBIT) is a framework created by ISACA for information technology (IT) management and IT governance. It provides a set of best practices for aligning IT with business objectives, optimizing IT resources, and managing IT-related risks and controls across an organization.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| BAI01 - Manage Programmes and Projects BAI01.09 - Manage programme and project quality |
1. Identify assurance tasks and practices required to support the accreditation of new or modified systems during programme and project planning, and include them in the integrated plans. Ensure that the tasks provide assurance that internal controls and security solutions meet the defined requirements. | Prime identifies compliance and regulatory violations at the design stage, ensuring that any issues are addressed early to support the accreditation of new or modified systems. By integrating these assurance tasks into project planning, it provides confidence that internal controls and security solutions meet defined requirements from the outset. |
| BAI02 - Manage Requirements BAI02.04 - Obtain approval of requirements and solutions |
1. Ensure that the business sponsor or product owner makes the final decision with respect to the choice of solution, acquisition approach and high-level design, according to the business case. Coordinate feedback from affected stakeholders and obtain sign-off from appropriate business and technical authorities (e.g., business process owner, enterprise architect, operations manager, security) for the proposed approach. | Prime enables the business sponsor or product owner to make informed decisions on the solution, acquisition approach, and high-level design by identifying security risks early in the design stage. It provides insights into potential vulnerabilities and gathers feedback from stakeholders, ensuring that decisions are aligned with both business objectives and security requirements. |
| BAI03 - Manage Solutions Identification and Build BAI03.01 - Design high-level solutions |
3. Create a design that is compliant with the organization's design standards, at a level of detail that is appropriate for the solution and development method and consistent with business, enterprise and IT strategies, the enterprise architecture, security plan, and applicable laws, regulations and contracts. | Prime ensures that designs comply with organizational standards by identifying security requirements and risks early in the development process. It aligns the design with business, enterprise, and IT strategies, the enterprise architecture, security plans, and relevant laws, regulations, and contracts. |
| BAI03 - Manage Solutions Identification and Build BAI03.02 - Design detailed solution components |
9. Proactively evaluate for design weaknesses (e.g., inconsistencies, lack of clarity, potential flaws) throughout the life cycle, identifying improvements when required. | Prime focuses on identifying security flaws during the design phase by evaluating potential weaknesses, such as inconsistencies, ambiguities, and vulnerabilities. It provides early insights and recommendations for improvement, ensuring that security issues are addressed before they progress further in the development lifecycle. |
Institute of Internal Auditors
The Institute of Internal Auditors (IIA) is a global professional association that serves as the primary advocate, educator, and standard-setter for the internal audit profession. It provides guidance, certifications, and resources to enhance the effectiveness of internal auditors in various industries, promoting ethical practices and professional excellence in risk management, control, and governance processes.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| F. How the organization addresses cybersecurity within their system development life cycle, including the following control aspects | 1. Planning: Cybersecurity has been identified as a key component when assessing risks and analyzing potential vulnerabilities. The scope and objectives of the software implementation should be included as the organization evaluates cybersecurity controls during the planning phase. |
Prime integrates cybersecurity risk assessments and compliance checks throughout the planning, requirements-gathering, and design phases of the SDLC. It identifies vulnerabilities early, ensures alignment with legal and regulatory standards, and recommends the necessary security controls that should be applied. Prime enables cyber security auditors to perform an effective audit process to ensure that security controls are being implemented at the design stage including formal audit evidence gathering. |
OWASP ASVS v4.0.3
Open Web Application Security Project (OWASP) is a nonprofit foundation dedicated to improving the security of software. It provides freely available articles, methodologies, documentation, tools, and technologies in the field of web application security.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| V1.1 Secure Software Development Lifecycle | 1.1.1 Verify the use of a secure software development lifecycle that addresses security in all stages of development | Prime integrates into the design phase of SDLC and provides the proper security practices before actual development starts |
CIS
The Center for Internet Security (CIS) is a nonprofit organization that develops and promotes best practice standards for cyber defense. CIS provides benchmarks, controls, and tools to help organizations improve their cybersecurity posture, with a focus on creating and maintaining consensus-based, vendor-agnostic security configuration guidelines for various IT systems and software.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| Control 16 - Application Software Security | 16.1 Establish and maintain a secure application development process. In the process, address such items as: secure application design standards, secure coding practices, developer training, vulnerability management, security of third-party code, and application security testing procedures. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. | Prime enables organizations to establish and maintain a secure application development process by identifying risks early and recommending security requirements aligned with best practices |
GDPR
The General Data Protection Regulation (GDPR) is a comprehensive data privacy law enacted by the European Union in 2018. It sets strict rules for how organizations must handle personal data of EU residents, including requirements for consent, data protection measures, and individuals' rights over their data.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| Article 25 - Data Protection by Design and by Default |
1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organizational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects. 2. The controller shall implement appropriate technical and organizational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. |
Prime helps organizations comply with data protection regulations by identifying cybersecurity risks during the design stage of the SDLC |
European Commission, Cyber Resilience Act
The European Commission is the executive branch of the European Union (EU). It proposes and enforces legislation, implements policies, and manages the day-to-day operations of the EU.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020 | (1) create conditions for the development of secure products with digital elements by ensuring that hardware and software products are placed on the market with fewer vulnerabilities and that manufactures take security seriously throughout a product's life cycle. | Prime enables the development of secure products with digital elements by identifying vulnerabilities early in the design phase and ensuring they are minimized before market release. |
Monetary Authority of Singapore
The Monetary Authority of Singapore (MAS) is Singapore's central bank and integrated financial regulator. It oversees all financial institutions in Singapore, manages the country's exchange rate, operates its monetary policy, and works to ensure financial stability.
| Control/Requirement ID | Control/Requirement Description | Compliance with Prime |
|---|---|---|
| 5.4 System Development Life Cycle and Security-By-Design | 5.4.2 The security-by-design approach refers to building security in every phase of the SDLC in order to minimize system vulnerabilities and reduce the attack surface. The FI should incorporate security specifications in the system design, perform continuous security evaluation, and adhere to security practices throughout the SDLC. | Prime implements a security-by-design approach by embedding specific security requirements during the design phase of the SDLC to minimize vulnerabilities and reduce the attack surface. It continuously evaluates the system for security risks and ensures adherence to best practices throughout development. |
| 5.6 System Design and Implementation | 5.6.1 As part of the design phase, the FI should review the proposed architecture and design of the IT system, including the IT controls to be built into the system, to ensure they meet the defined requirements, before implementation. | Prime facilitates the review of the proposed IT system architecture and design during the design phase to ensure that all security controls align with defined requirements. |
The Future of Security by Design in Agile and CI/CD Environments
The evolution of Security by Design from a reactive, optional approach to a regulatory guideline reflects the increasing importance of cybersecurity in the modern world. As cyber threats continue to evolve, organizations can no longer afford to treat security as an afterthought. SbD ensures that security is a foundational element of system architecture, and compliance with international standards is critical to maintaining secure, resilient systems. By embracing SbD principles, organizations can protect their assets, meet regulatory requirements, and build trust with users in an increasingly interconnected digital landscape.
The rise of Agile development, alongside Continuous Integration and Continuous Delivery (CI/CD) practices, presents new challenges to the current, manual approaches. As CI/CD pipelines speed up the development and deployment cycles, the rapid pace of automation can reduce the capacity of human security architects to deliver timely and precise security guidance, and hence become a blocker to the business. To effectively address these challenges, the “Security by Design” framework must be reinforced by automated software tools, such as Prime, that can integrate security checks and controls seamlessly into the accelerated development process.
Security Design Reviews vs. Threat Modeling (April 2026)
The Nuances of Design Stage Security
If you work in cybersecurity (or security adjacent) you are very familiar with the 2 main practices that help to identify and remediate security concerns before development starts; Threat modeling and Security Design Reviews. Both are practical capabilities, and while threat modeling has a variety of frameworks, design reviews are more of a delicate and tactical process that heavily relies on an intimate knowledge of the business. But have you ever felt like your security reviews are missing the mark? Maybe they’re too generic or don’t account for the unique risks your business faces. The challenge often lies in capturing that elusive business context. While threat modeling is a powerful tool, it often happens to be a hammer, and so reluctantly security has to see every design problem as a nail. This makes threat modeling a default approach even when a more nuanced method, like targeted security reviews, would be more effective. By harnessing Large Language Models (LLMs) to sift through unstructured data, we can finally bring the vital context needed to scale security reviews across the board and provide a supercharged version of this method to security practitioners.
Context: The Critical Factor
Traditional security checks often fall short because they can’t adapt to the specific nuances of your business, and threat modeling alone can’t address all the intricacies of secure development. This is where LLMs come into play. By leveraging new LLM empowered capabilities early in the design stage of the SDLC, we can enhance security reviews with deeper context and precision, making them more effective and efficient. This approach allows you to weave security into your systems right from the start, rather than relying on exhaustive modeling for every scenario.
Providing developers with business-driven, concrete security requirements upfront reduces friction and ensures the right tools are used at the right time. By leveraging security reviews at scale for ongoing, contextual feedback, development teams know exactly what’s expected before writing a single line of code, minimizing rework and keeping projects on track. It substantially reduces the dependency on sometimes very cumbersome threat modeling processes that can be an overkill for the task at hand.
Prime Security: Embedding Security before Development starts
At Prime, we focus on security design reviews because we know they’re the most practical and proactive way to secure products from the ground up. By providing the infrastructure to capture and integrate business context, Prime ensures that your security reviews are tailored to the specific needs of your organization. The result? A product that’s secure by design, allowing your teams to move fast without sacrificing security.
Product Velocity is Dependent on Product Security
The Cost of Security Stepping in Too Late
It’s a common problem: product development is moving fast, but once security steps in late, everything slows down. As companies grow and products become more complex, security often gets pushed to the end of the process. By then, code is written, deadlines are looming, and vulnerabilities surface. The result? Expensive delays and missed opportunities:
- Development teams scramble to rework code, adding up to 40% more time to the release cycle.
- Release schedules slip, increasing operational costs by 20-30%.
- Customers grow frustrated as features are delayed, leading to negative feedback.
- The relationship between Security and Engineering becomes strained, slowing progress even further.
This isn’t just frustrating—it’s costly. Fixing security issues late in the process can cost up to 10 times more than addressing them earlier. The core issue? Security and engineering aren’t working together early enough.
It's a People, Process, and Technology Problem
Today, companies rely on traditional security processes such as Security Design Reviews, Threat Modeling, and Security Champions programs to bridge the gap between Security and Engineering. According to the SANS DevSecOps Survey, most organizations recognize the value of up-front risk assessments, with over 80% of respondents acknowledging the benefits of early security involvement. However, few consistently implement these assessments early in the development process.
Why? It’s not just a technology issue—it’s a people and process problem too. Security design reviews and threat modeling are often manual, time-consuming, and difficult to scale across fast-moving development cycles. Programs like Security Champions, while valuable in theory, suffer from inconsistent adoption and execution, leaving critical gaps that can be costly to address later.
In a world where businesses need to move quickly to stay competitive, relying on manual, late-stage security processes becomes a significant bottleneck. Addressing vulnerabilities during the design phase is up to 10x cheaper and 70% faster than fixing them post-release. For organizations that rely on fast, iterative releases, every delay can compound, affecting market share, customer satisfaction, and overall growth.
Prime Security’s Approach
At Prime Security, we focus on maintaining product velocity by seamlessly integrating security into the planning and design phases, without disrupting existing workflows. Our platform connects directly with your company’s development tools—like Jira and Confluence—so security becomes part of the process without requiring developers to change their behavior. By automating the identification of risks and providing full visibility into potential issues before any code is written, Prime Security enables teams to take a preventative approach, addressing critical concerns early and keeping development on track. Rather than overwhelming developers with complex security tasks, we simplify the process by offering clear, actionable insights that allow Security and Engineering to collaborate efficiently. Prime Security delivers immediate time-to-value, with actionable insights available within 24 hours of implementation, ensuring teams can avoid last-minute delays and keep the development pipeline running smoothly.
Final Thoughts
When security is left to the end of the development process, product velocity inevitably suffers. But when Security and Engineering collaborate from the start, teams can avoid delays, meet their deadlines, and deliver secure, reliable products faster. By embedding security in the design phase, companies not only prevent costly delays but also gain a competitive advantage by consistently delivering secure, high-quality products at speed. At Prime Security, we help companies shift security left, empowering teams to move quickly without sacrificing security.
Building Prime Security
As security professionals and technical leaders we’ve experienced the main pain in developing products. The constant struggle of balancing development velocity with security needs. Through it all, one thing became clear, many security challenges could be prevented given the right context at the design phase of the SDLC. Too often, security comes in at the last minute, scrambling to apply fixes after development is complete, leaving both teams frustrated and out of sync.
Sure, security exists in the SDLC today, but it starts to scale when code is written. You can scan for dependencies, catch bugs, and identify vulnerabilities. But Product Security shouldn’t start with code scanning; it needs to start with design. It’s not just about applying processes or enforcing policies; it’s about influencing decisions before a single line of code is written. Security teams need actionable insight into what’s being built and why, from the earliest stages. But extracting that insight is challenging, scaling it across fast-paced teams is even harder, and making it stick while everyone’s sprinting to meet deadlines can feel nearly impossible.
That’s why we built Prime Security. To truly integrate security into modern development, it has to start at the design phase, not after. We’re not here to slow development down; we’re here to give security engineering teams superpowers so they can support developers to make smarter decisions, faster - embedding security directly into their workflows.
With our unique business and security context extraction engine, Prime Security automates risk assessments and generates tailored mitigation recommendations, ensuring that security isn’t just an afterthought, but a partner in the development process. Prime brings hard-won insights from security professionals right to the point where they’re needed most. This isn’t about adding friction; it’s about unlocking development velocity without compromising on security.
This is the future of Product Security: practical, scalable, and context-driven decisions, integrated from day one. With Prime, security and development teams can truly build securely from the start, setting a new standard for scalable, design-first security. We’ve lived through these challenges, and we’re here to solve them, for good.
Michael, Dimitry, Danny, Matan
