Here are two numbers from my Git repository.

Over the past quarter of building with — and deliberately experimenting on — agentic development practices, my CLAUDE.md grew from 154 lines to 155.

In the same period, the .claude/ directory beside it grew to 28,431 lines across 118 files.

That is a ratio of roughly 183 to 1. And the context file growing by exactly one line was not stagnation or neglect — it was the design goal. Everything I have learned about making agentic development work in earnest is contained in why that ratio looks the way it does.

This piece covers five things: the failure mode almost everyone hits first; the reframe that fixed it; the six layers where the real weight now lives; the security and governance lens that ties the layers together; and what the arrangement bought me in measurable terms. The argument that frames all of it: a context file is an index, not a manual.

1. The failure mode everyone hits first

If you have used Claude Code, Cursor, or any comparable agentic tool for more than a week, you will recognise the arc:

1. You start with a small, tidy context file.

2. The agent does something wrong — uses the wrong naming convention, skips a test, logs a user’s email.

3. You add a rule to the file.

4. Return to step 2.

Six weeks later your context file is a 900-line wall of imperatives — and, here is the hard truth, the agent ignores it more than it did when the file was small. This is not mere anecdote: Anthropic’s own guidance names the over-specified context file as an anti-pattern, and the creator of Claude Code keeps his own team’s file deliberately short — his advice when it bloats is to delete it and start again.

However, this is not the model being lazy. It is three structural problems compounding:

Everything loads on every request. Your migration rules are in context when the agent is fixing a CSS bug. Your CSS conventions are in context when it is writing a database trigger. Every irrelevant rule is noise diluting the relevant ones.

Instruction-following degrades with volume. A model attending to 40 rules follows them noticeably worse than a model attending to 8. Past a certain point, each rule you add reduces compliance with the rules you already had.

Prose rules are requests, not enforcement. “Never commit directly to main” is an instruction. I have experienced multiple times that the agent can lose the thread in a long session or get confused across a subagent handoff — and the instruction does nothing. The distinction that matters: an instruction is something an agent can ignore, whereas a rule is something that can be enforced. A “rule” that exists only in prose is not a rule at all — it is an instruction wearing a rule’s clothing.

I hit all three. An early version of my context file had the engineering standards inlined in full — naming tables, the TDD workflow, security rules, the lot. About a month in, I gutted it in one deliberate restructuring: the standards moved out, and what stayed behind was pointers.

For example, my testing guidance used to live in the context file as prose:

Testing. We follow strict TDD: write a failing test first (RED), write minimal code to pass (GREEN), then refactor. Coverage must stay above 80% on branches, functions, lines, and statements. Unit tests are co-located next to source files. Never use test.only() or test.skip() in committed code. Integration tests live in…

…and so on, for every discipline. After the restructuring, the same topic occupies one row of a table:

One sentence of essence, one pointer to the file that owns the detail. That pattern, repeated across every engineering concern, is how the file lost hundreds of lines of prose while gaining authority.

2. The reframe: an index, not a manual

The mental model that fixed this for me: a context file is a README plus a routing table. Its job is to tell the agent what exists and where to look — not everything there is to know.

My current 155 lines contain four things:

• Short project overview — stack, packages, status; what any new collaborator needs in the first thirty seconds.

• Principles table — 39 engineering principles, each one sentence, each with an “Owner” column pointing at the file that holds the normative detail.

• Essential commands (npm test, the full verification gate, and friends).

• Skill Navigator — a map of where the deep standards live and which auto-loaded rules exist.

Almost nothing normative lives in the file itself. Moreover, the file says so explicitly, in a line I would now call the most important one in it:

“This is a navigation index. The Owner column points to the file containing the normative detail. Update standards/rules — never duplicate definitions here.”

That is the single-source-of-truth principle, applied to agent instructions exactly as you would apply it to code. The moment a rule exists in two places, the copies drift, and the agent follows whichever version it happened to read.

3. Where the 28,000 lines actually live: the six layers

So if the context file is thin, where did the weight go? Into six layers, ordered from “always loaded” to “physically cannot be ignored”. This stack is the real answer to “how do you make agents follow the rules?”

Layer 1: the context file — always loaded, pure navigation. 155 lines index file.

Layer 2: path-scoped rules — loaded when relevant. Ten short, numbered files (coding, API routes, database, security, testing, AI…) that auto-load based on what the agent is touching. Working on an API route? The route pattern and schema-validation rules are in context. Writing a React component? They are not. Each file is terse — constraints only, no tutorials — because it loads alongside live work. This layer alone fixed most of the “irrelevant rules as noise” problem.

Layer 3: standards skills — loaded on demand. Eleven deep standards (testing, security, architecture, error handling, git, database, and so on), each a directory with a skill file plus reference documents. This is where the bulk of the 28,000 lines sits: full TDD workflows, row-level-security policy patterns, error taxonomies, migration safety procedures. None of it loads until the work calls for it — and when it does load, it is the complete treatment, not a summary that loses the edge cases.

Layer 4: subagents — context isolation by role. Ten specialised agents (developer, test-designer, code-reviewer, critic, architect…), each with its own role definition, allowed tools, and operating modes. The point is not merely specialisation — it is that each agent carries its own scoped context instead of inflating one giant session. The test-designer knows the testing standard intimately and does not need the deployment runbook.

Layer 5: hooks — where “please don’t” becomes “you can’t”. This is the layer that changed how I think about agent reliability. Tool-use hooks run before every file write: one blocks writes to sensitive paths (.env, keys, .git/) outright; another logs every modification to an audit trail; and a fail-closed write-scope engine enforces capabilities — the developer agent literally cannot edit test files, the test-designer literally cannot edit implementation files, and no agent can edit the workflow configuration itself, because the hook denies those paths too. These are not instructions the agent might forget. They are denials at the tool layer. The prompt could say “ignore all rules” and the hook would still refuse the write.

Layer 6: CI gates — the backstop that does not care what anyone intended. Git hooks enforce branch naming, conventional commits, and a full verification gate before push. CI enforces a coverage gate on changed files, an architecture-alignment check that validates the diff against machine-readable architecture documents, lint, type-checks, and a secrets scan. By the time code reaches a pull request, it has passed gates that no amount of agent confusion can talk its way through.

The organising principle across all six layers, stated plainly:

Push every instruction down to the cheapest layer that can enforce it.

Prose is the most expensive and least reliable enforcement mechanism — it consumes context on every request and depends entirely on the model’s attention. Tool-level denial and CI checks are the cheapest and most reliable — they consume zero context and cannot be ignored. Put differently: the workflow itself is deterministic — scopes, gates, and pipelines behave identically on every run — and the model’s stochastic intelligence is spent only where judgement is genuinely required: designing, implementing, reviewing. Determinism owns the rails; intelligence rides on them. A rule should only live in the context file if no lower layer can hold it.

4. The security and governance lens

It took me a while to notice what I had actually built, because I had seen it before — just never applied to an AI. This is control design. An agent with write access to a codebase is a privileged user, and twenty plus years in cybersecurity says you never govern a privileged user with a policy document alone. You govern them with controls:

Seen through this lens, the six layers stop being a productivity hack and become a governance architecture: policy expressed as versioned, reviewable files; enforcement pushed into mechanisms the governed party cannot alter; and an evidence trail for every decision. However, the inverse also holds — if your agentic setup has none of these properties, you have granted a tireless, fallible collaborator unrestricted production access and a polite request to behave. Few organisations would accept that posture for a human contractor. It is worth asking why we accept it for agents.

5. What this bought me

The payoffs were concrete, not aesthetic.

Instructions stopped being ignored — because most of them stopped being instructions. The rules that matter most are no longer competing for the model’s attention; they are hooks and gates.

Violations became measurable and fixable. For example, when I decided to ban unsafe type assertions, I did not add a paragraph of prose — I added a short rule plus lint enforcement, and double-casts in the codebase dropped from 17 instances to 2 audited bridge modules. When agent handoff documents kept failing validation on false positives, the fix was schema validation with drift detection, and false failures dropped from 62 to 6. Prose cannot produce numbers like that; mechanisms can.

Maintenance collapsed to single edits. When a standard changes, I edit one file. The index never needs updating because it never contained the detail. No drift, no archaeology, no “which version of this rule is current?”

6. The honest caveats

Three things to know before copying any of this.

It was not designed up front. This harness co-evolved with the work over the quarter, through a steady stream of deliberate tooling changes. The layers appeared in response to real failures, in roughly this order: the architecture documents became machine-checkable early on; the rules extraction happened around the one-month mark; the specialised agents and pipelines matured over the following fortnight; the capability-based write scopes landed last. Do not build six layers for a weekend project.

Each layer has a trigger. Extract rules out of your context file when it passes ~200 lines. Add a hook when an agent violates the same prose rule twice. Add a CI gate when a violation makes it all the way into a pull request. Let the failures tell you which layer to build next.

Some of it is still aspirational — and the index says so. My principles table honestly tags rows as partial, pending, or aspirational. AI-behaviour evals, for example, are a stated principle with a defined boundary but harness to be built yet. An index that claims more enforcement than actually exists is worse than no index — agents and humans alike learn to distrust it.

Final Thoughts

The context file didn’t scale. The architecture around it did.

The instinct, when an agent misbehaves, is to write a longer manual. The discipline that actually works is the opposite: a smaller index, with every instruction pushed down to a layer that can genuinely enforce it — scoped rules, on-demand standards, role-isolated agents, tool-level denials, and pipeline gates that do not negotiate. Persuasion is a last resort, not a strategy.

This is the first post in a series on how my agentic harness has evolved — and it is the only one that argues from principle. The posts that follow take the layers one at a time: architecture documents that bite back when code drifts from them; path-scoped rules in depth; agents treated as versioned APIs with schema-validated handoffs; capability-based write sandboxing; making RED-GREEN-REFACTOR agent-proof; the time I audited my own pipeline with 129 agents; and the eval harness that I am building.

If your context file has been growing while your compliance has been shrinking, the ratio at the top of this post is the diagnosis — and the next post is the first treatment. Subscribe and the series lands in your inbox, one layer at a time.

And before you go, I would genuinely like to hear it: what is the largest context file you have let an agent ignore?

The Conversation

The Cybersecurity team has recently completed a vulnerability scan on one of the business applications and has identified a ‘critical severity’ vulnerability.

The team reports the finding to the business, and this is how the conversation goes.

Cyber: We have found a ‘critical severity’ vulnerability in your application. You need to fix this within ’n’ number of days. (Replace ’n’ with any number as defined by your SLA.)

Business: What does this ‘critical severity’ vulnerability mean?

Cyber: The security scanning tool has identified a blind SQL injection vulnerability in your application that an attacker could exploit to compromise the backend database. The scanning tool has rated the vulnerability as ‘critical severity’, which means you need to fix it within ’n’ number of days as per the SLA.

Business: I understand, if the database can be compromised by exploiting a SQL injection vulnerability, it appears pretty bad. But we don’t have any sensitive data in our database, and the application is accessible only to a few internal company employees.

Business asks to Cyber:

So, Mr. Cyber, please explain what is the actual business risk posed by this vulnerability in the context of my application?

Cyber: We do not work in this way. Since we scan a large number of applications and do not have the data to understand the context, we require all ‘critical severity’ vulnerabilities highlighted by our tools to be resolved before you can go live or within ’n’ number of days.

Business: We have committed a target release date to our customers. Since we’re already behind on this delivery, I cannot allow any further delays because of this vulnerability in our application.

Business: I do not see a material risk to the business here, so I will accept the risk for nowand deal with it later when we have more time (which effectively never happens).

(The discussion ends there.)

The Disconnect: Cyber Risk vs. Business Risk

The discussion above is not an isolated instance but a recurring theme that I have encountered many times in my career, and I’m sure you would have too.

The issue here is that both Cyber and Business are looking at the same issue, but they evaluate it through entirely different lenses.

Let’s find out what exactly does that mean!

Cyber’s Focus: Technical Risk

Cyber teams rely heavily on technical risk ratings following methodologies such as CVSS (Common Vulnerability Scoring System). These ratings are derived from likelihood, impact, and other technical factors. A ‘critical severity’ rating automatically triggers stringent SLAs for remediation.

Business’s Focus: Operational Risk

Business teams assess risk through the lens of operational risk which generally involves operational impact, customer commitments, revenue, and regulatory compliance. A vulnerability may be rated ‘critical severity’ technically, but if the application is non-sensitive, limited in exposure, or non-core to operations, the business may consider the risk negligible and hence decide to lower the severity rating and accept the residual risk.

This disconnect often results in frustration on both sides —

The Cyber team feels the Business is not taking security seriously, while the Business views Cyber as creating unnecessary roadblocks.

Example Scenarios

Consider these two scenarios that bring this to life —

Scenario 1: High Technical Risk, Low Business Impact

• Scenario: A vulnerability is discovered in a reporting application used exclusively by the finance team. The application is hosted on an internal network with limited access.

• Cyber’s View: The vulnerability is technically ‘critical’ because it allows privilege escalation, and the CVSS score is 9.8.

• Business’s View: The database behind the application only contains non-sensitive financial summaries that are of little value to attackers. Since the application is restricted to internal users and has additional network segmentation, the business deems the risk acceptable.

Scenario 2: Overlooked Technical Risk, High Business Impact

• Scenario: A medium-severity vulnerability (CVSS 5.4) is found in a customer-facing e-commerce platform. Exploiting the vulnerability could allow attackers to scrape customer emails.

• Cyber’s View: Since the vulnerability is rated as ‘medium’ by the scanning tool, it doesn’t meet the SLA threshold for immediate remediation.

• Business’s View: Exposing customer data — even emails — could result in reputational damage and regulatory fines under GDPR. The business considers this a critical issue and expects immediate action.

Why this Disconnect happens?

From the discussion above, it is evident that both Cyber and Business operate in silos, leading to a significant disconnect. Not only that, there could also be cultural, organisational, and leadership factors contributing to this disconnect.

Some of the potential causes for disconnect could include:

1. Differing Objectives and Priorities

• Cyber’s Objective: Cyber is working to protect the organisation by mitigating security risks. Cyber teams are often measured on metrics like the number of vulnerabilities remediated, adherence to SLAs, and incident prevention.

• Business’s Objective: Business delivers products and services to customers on time, maintaining profitability, and achieving operational goals. Business teams are focused on metrics like revenue, customer satisfaction, and operational efficiency.

The fundamental difference in objectives result in misaligned or even competing priorities. Cyber sees vulnerabilities as threats to organisational security, while Business sees them as potential delays to key deliverables.

2. Misaligned Risk Definitions

Cyber often uses metrics like CVSS scores, CWE classifications, and SLA adherence to assess risk. Business relies on operational risk frameworks that account for financial loss, reputational impact, and regulatory compliance, which may not directly correlate with CVSS scores.

The absence of shared, agreed-upon metrics for assessing risk means that both sides are speaking different languages.

For example, Cyber might insist on remediating a vulnerability because it’s ‘critical’ by CVSS standards, but Business might ignore it because it doesn’t align with their financial risk threshold.

3. Tool-Centric Approach

Security scanning tools are designed to highlight technical risks but lack context of the application environment, data sensitivity, or exposure. Without this context, vulnerabilities may be incorrectly prioritised.

Also, a number of scanning tools, such as SAST, DAST, SCA, container scanning, secrets scanning, infrastructure scanning etc. may generate a lot of noise due to the presence of false positives and duplicate findings.

Not having a streamlined process to triage vulnerabilities and to remove duplicates may result in toil for Business and development teams.

4. Lack of Communication

In many organisations, Cyber and Business teams operate in silos with minimal interaction. This isolation leads to a lack of understanding of each other’s goals, challenges, and constraints. A Cyber team may not be aware of a looming product launch deadline, while Business might not understand the technical implications of delaying a patch for a critical vulnerability.

Also, security teams often fail to communicate the “so what?” to the business. Explaining technical vulnerabilities in terms of their potential business impact requires effort and collaboration but is often overlooked.

5. Cultural Barriers

The cultural mindset within Cyber and Business teams can also differ significantly:

• Cyber tends to have a defensive mindset, prioritising caution and mitigation of potential threats.

• Business is more risk-tolerant, focusing on achieving outcomes even if it involves taking calculated risks.

This cultural difference often leads to Cyber being seen as “the department of no”, while Business is viewed as “recklessly ignoring security”.

6. Perception of Security as a Cost Centre

Business often views Cyber as a cost centre that consumes resources without directly contributing to revenue. This perception leads to security being deprioritised, especially when budgets or timelines are tight.

As a result —

Cyber struggles to gain buy-in for remediating vulnerabilities unless they can directly tie their efforts to business value, such as avoiding regulatory fines or improving customer trust.

9. Inconsistent Leadership Alignment

Leadership plays a crucial role in bridging the gap between Cyber and Business. Inconsistent or misaligned leadership priorities can exacerbate the disconnect:

• Cyber Leadership: May focus on compliance metrics or industry benchmarks without fully considering the organisation specific business needs.

• Business Leadership: May underappreciate the importance of cybersecurity or fail to advocate for risk management at the executive level.

This lack of a unified vision at the leadership level trickles down to operational teams, perpetuating the misalignment.

Bridging the Gap

To address these challenges, it is important to shift the focus on implementing actionable strategies that results in collaboration and alignment between Cyber and Business objectives.

Let’s review what some of these strategies may involve —

1. Adopt Risk Contextualisation

Security teams must move beyond generic technical ratings like CVSS scores and incorporate environmental and business context when assessing vulnerabilities. This means considering factors such as:

• Application Criticality: Is the application central to business operations or customer interactions?

• Data Sensitivity: Does the application handle personal, financial, or regulated data?

• Exposure: Is the application externally accessible or restricted to internal users?

For example, an SQL injection vulnerability in an Internet facing application with sensitive customer data is far riskier than the same vulnerability in an internal reporting tool used by a small team.

Tools like EPSS (Exploit Prediction Scoring System) can also help by estimating the likelihood of exploitation, which adds another layer of prioritisation.

Leverage AI or automation tools to enrich vulnerability data with contextual business information.

For example, a tool that links vulnerabilities to asset importance, exposure, and data classification can provide a more accurate risk picture.

2. Risk Based Vulnerability Management (RBVM)

Transition from a “fix everything critical” approach to a more strategic “Risk Based Vulnerability Management” approach. This involves:

• Using a custom risk scoring methodology that combines both technical and business risk.

• Aligning vulnerability management with operational risk framework to ensure consistent prioritisation.

For example, an RBVM framework could consider the CVSS score, exploit likelihood, data classification, financial impact, and regulatory exposure, assigning weights to each of these factors to calculate a composite risk score.

This ensures vulnerabilities are prioritised based on their overall risk to the organisation and not just the technical risk factors.

3. Streamline Processes

The sheer volume of vulnerabilities generated by multiple scanning tools often leads to noise and duplication.

To reduce toil —

• Consolidate vulnerability data into a centralised repository to de-duplicate findings from tools like SAST, DAST, and infrastructure scans.

• Implement workflows to automatically categorise vulnerabilities based on criticality and context.

• Create a single “source of truth” dashboard where all teams can see prioritised vulnerabilities and remediation status.

4. Train Both Teams

Cross-training is essential for fostering collaboration and understanding between Cyber and Business.

• For Cyber Teams: Conduct workshops on business operations, regulatory requirements, and the company’s risk management framework. This helps them understand why Business might prioritise or deprioritise certain vulnerabilities.

• For Business Teams: Provide basic training on cybersecurity concepts, such as CVSS, attack vectors, and threat modeling, so they can appreciate the implications of vulnerabilities.

For example, Cyber could organise a “day in the life of a vulnerability” session to walk Business teams through the potential exploitation of a vulnerability, its impact, and remediation options.

5. Continuous Feedback and Improvement

Vulnerability management is an iterative process. Continuous monitoring and feedback loops ensure alignment over time.

To make improvements over time —

• Monitor key metrics, such as the number of vulnerabilities remediated within SLA, average time to remediate, and business satisfaction scores.

• Collect feedback from both Cyber and Business teams after major vulnerability management cycles to identify pain points.

• Adjust processes and tools based on lessons learned to work more collaboratively.

6. Leadership Alignment

Taking a top-down approach where leadership can develop shared vision, establish unified risk management frameworks, and drive cultural change in the organisation. This may include —

• Estabilishing unified objectives that integrate security into business goals, ensuring alignment across all teams.

• Establishing unified risk management framework where both Cyber and Business teams evaluate risks using common metrics that combine technical and business impacts.

• Developing governance model, such as a joint risk committee, can ensure continuous collaboration and alignment between Cyber and Business priorities, driving cultural change in the organisation.

Final Thoughts

The conflict between Cyber and Business on vulnerability management isn’t about one side being right and the other wrong. It’s about finding a common ground. By contextualising risk, adopting a risk-based approach, streamlining workflows, and fostering collaboration, organisations can align Cyber and Business priorities.

The ultimate goal is for Cyber to serve the Business by enabling it to operate securely without unnecessary delays or toil.

And the end result would be —

A more secure, efficient, and harmonious working environment where both sides contribute to shared business goals*.*

The transition from DevOps to DevSecOps is a journey that is both rewarding and challenging. While DevOps emphasises collaboration and efficiency in software delivery, DevSecOps seeks to embed security into every phase of the software delivery process.

By adopting DevSecOps practices, organisations not only deliver secure software faster, giving them a competitive edge, but can also demonstrate continuous compliance with internal policies and external regulatory requirements.

However, the journey may not be as straightforward. While the benefits of DevSecOps are clear, organisations often encounter significant barriers that hinder this evolution, making the process challenging. This shift goes beyond changes in processes and technology and requires a fundamental shift in mindset and organisational culture too.

In one of my earlier articles, I discussed the importance of this cultural shift and highlighted how embracing a security-first mindset is crucial for successfully embedding security into every aspect of the software development process.

In this article, I will explore some of the key technical, process, and cultural barriers that DevOps teams typically face during this transition and share strategies on how organisations can address these challenges.

Major Challenges to DevSecOps Adoption

Challenges that the DevOps teams face while integrating DevSecOps practices in their workflows:

#1. Cultural Resistance — Speed vs Security

Resistance to change is one of the most significant barriers to adopting DevSecOps. Teams accustomed to the speed and agility of DevOps often perceive security as an additional burden. They may fear that incorporating security practices will slow down the delivery cadence and add new layers of complexity. This is especially true for fast-paced DevOps teams who are accustomed to releasing updates multiple times a day.

This resistance is further exacerbated by a fear of accountability, as integrating security increases scrutiny and may expose vulnerabilities. Such a mindset may result in rushed releases with minimal security validation, leaving software vulnerable to attacks in production environments.

Siloed mentalities also pose a significant challenge. Security has traditionally been the domain of a separate team, leading to a “not my responsibility” mindset among developers and operations teams. Additionally, security is often perceived as a bottleneck, and making its integration into the development process feels more like an intrusion than a shared responsibility. Teams working under aggressive timelines may prioritise speed over security, creating a conflict between short-term goals and long-term resilience.

While cultural barriers are significant, they are often compounded by technical challenges, such as integrating security tools effectively into existing workflows.

#2. Tools Overload and Integration Complexity

With DevSecOps, multiple tools are introduced to automate security tasks, such as SAST, DAST, secrets scanning, container security, and vulnerability scanning etc. While these tools enhance security capabilities, they can also overwhelm teams, particularly when they do not integrate seamlessly with existing CI/CD workflows.

Poor integration may lead to siloed data from multiple scanning tools, requiring manual intervention to consolidate results. This creates inefficiencies, slows down delivery timelines, and complicates the detection of critical vulnerabilities across different stages of the development process. Furthermore, disconnected tools contribute to friction within workflows, making it harder for teams to maintain a consistent security posture.

The use of multiple tools can also result in duplicate reports of the same vulnerability, often with differing severity ratings and varying contextual information. This inconsistency adds to the confusion among development teams, making it harder to prioritise and address security issues effectively.

Use tools that embed security checks into the developer workflow without disrupting their daily workflows (e.g. SAST tools integrated into CI/CD pipelines). Consider consolidating findings from multiple tools and build a centralised dashboard for security alerts to reduce tool and vulnerability overload.

These operational hurdles are compounded due to lack of security expertise within development teams. Without the necessary skills, developers may struggle to interpret security findings and implement appropriate remediation, further delaying the resolution of vulnerabilities.

#3. Lack of Security Expertise in Development Teams

DevSecOps requires developers to take on additional security responsibilities that they may not be familiar with, such as performing vulnerability scans, interpreting results, and implementing appropriate fixes. This shift often leads to a knowledge gap, as many developers are experts in writing code but lack experience with security best practices.

When vulnerability descriptions are unclear, developers may mark these security issues as low-priority technical debt, accept the associated risks, or may even mark these as false positives. These actions can create a false sense of security, leaving vulnerabilities unaddressed and exposing the software to potential exploitation in production environments.

To bridge the expertise gap, organisations can invest in targeted security training programs and consider embedding security champions within development teams.

Conduct regular security training sessions on topics like OWASP Top 10 and secure coding practices. Developers should be trained to understand security vulnerabilities identified by automated tools and how to remediate them. Peer security reviews and security hackathons can also be helpful in increasing awareness and ownership of security issues.

Security champions can act as liaisons, ensuring developers receive timely support and guidance on complex security issues. These measures can enhance developers’ understanding of security practices, enable them to handle vulnerabilities effectively, and foster a culture of shared responsibility for security.

#4. False Positives and Alert Fatigue

Security tools, particularly during early adoption phases, could produce a high volume of false positives, leading to alert fatigue. Developers may become desensitised to security alerts, potentially ignoring critical vulnerabilities that can get lost in the noise. This increases the likelihood that a real security vulnerability goes undetected and makes it into production, increasing security risks.

To mitigate these early adoption challenges, closely monitor the early iterations of tool integration within the pipeline to assess the rate of false positives. Fine-tuning security tools to reduce false positives is essential to ensure that security issues are accurately classified and prioritised for remediation.

Setting up custom rule sets and fine-tuning security tools to your organisation or system specific context, allowing the tools to flag only critical or high severity vulnerabilities will help prevent alert fatigue in the beginning. Tailored rule sets not only reduce alert fatigue but also improve developer productivity by allowing them to focus on high-priority issues. Once improvements have been made, the vulnerability identification scope can be expanded gradually to include medium and low severity issues.

Additionally, implement an automated risk-based prioritisation system to ensure that the most critical issues are addressed first. Create feedback loops between developers and security teams to help improve the accuracy of these tools over time.

By addressing alert fatigue early, organisations can foster greater trust in security tools and promote a collaborative security-first culture.

#5. Balance between Automation and Human Oversight

While automation is a key tenet of DevSecOps, not everything can, or should, be automated. False positives highlight the importance of striking a balance between automation and human oversight to ensure critical vulnerabilities are not overlooked. Complex threats and critical security decisions still require human oversight to provide the necessary context and judgment and therefore may pose challenges and may potentially cause delays that would need to be managed.

It is generally debated that the security gates should be replaced with appropriate guardrails within CI/CD pipelines. While this approach is generally effective, manual intervention is still necessary in certain scenarios, acting as a dual control mechanism. For instance, manual peer reviews during code commits and manual approvals before deploying to production ensure that critical vulnerabilities are thoroughly examined at appropriate stages in the CI/CD pipeline. Beyond these steps, automation should handle the majority of tasks, with appropriate guardrails applied at each stage of the software delivery process.

Some of the edge cases may include automating security checks in the pipeline but certain vulnerabilities, such as logic flaws, may still require manual reviews and contextual decisions that automation couldn’t handle effectively. Over-reliance on automation can lead to missed vulnerabilities or misclassifications that require deeper analysis.

Implement automated tools for tasks like code scanning, dependency analysis, and configuration checks, but schedule periodic manual code reviews, especially for high-risk areas like authentication and authorisation logic. Security engineers or champions couldbe involved in reviewing critical vulnerabilities flagged by automated tools to provide deeper analysis where necessary.

#6. Legacy Systems and Technical Debt

Many organisations operate with a mix of legacy systems and modern applications. Integrating security into legacy systems can be particularly challenging, as these systems were not designed with security or automation in mind. This results in compatibility issues with modern security tools, creating bottlenecks or necessitating additional workarounds to incorporate security measures effectively.

Generally, the security vulnerabilities in legacy systems are harder to address, and patching them often requires significant manual effort, which can slow down the DevSecOps transformation.

Consider how to reduce the technical debt for these systems over time. A potential solution might be to develop a strategy for gradually securing legacy systems while prioritising modernisation, however, this is easier said than done. Potential approaches may include segmenting legacy systems to isolate them from modern, secure environments or refactoring critical components to align with current security practices.

These technical challenges are further compounded by leadership misalignment, which can derail DevSecOps transformation efforts in the organisation.

#7. Leadership Misalignment

Leadership misalignment is another critical factor that can hinder the adoption of DevSecOps practices. Without strong leadership support and clear alignment on security goals, the necessary investments in modernisation and security integration may fail to gain traction.

Mixed messages from leadership about whether speed or security should take priority can cause confusion, undermining efforts to align teams and foster a unified approach.

Consistent, top-down advocacy is essential to ensure that security is prioritised alongside delivery speed, enabling teams to collaborate effectively and embrace DevSecOps principles.

Strategics to Overcome Challenges

Leadership Support

Leadership must champion the shift and set clear priorities.

Leadership plays a critical role in driving the cultural and operational shift required for DevSecOps. Leaders must actively champion the initiative, setting clear priorities that emphasise security as a core value. By aligning strategic goals with DevSecOps principles and fostering an environment where security is prioritised alongside speed and innovation, leadership can inspire teams to adopt and sustain these practices.

Cross-functional Collaboration

Break down silos with shared goals, open communication, and mutual accountability.

Breaking down silos between development, operations, and security teams is essential for success. Organisations must establish shared goals, facilitate open communication, develop communities of practice, and create mutual accountability across all teams. Regular cross-team collaboration fosters trust, ensures alignment, and integrates security seamlessly into existing workflows, making it a shared responsibility.

Building a culture where security is everyone’s responsibility is critical. The shift to DevSecOps must emphasise that security isn’t an afterthought or a blocker but a necessary component for building resilient software.

Security as an Enabler

Frame security as a tool for empowerment rather than restriction.

Reframing security as a tool for empowerment rather than a restriction is key to overcoming resistance. When teams understand that security strengthens their work — protecting users, the organisation, and the software they develop — it becomes easier to integrate into workflows. Positioning security as a contributor to quality and innovation helps dispel the perception of it as a bottleneck.

Training and Upskilling

Equip teams with knowledge and tools to integrate security seamlessly.

Equipping teams with the right knowledge and tools is vital for successful DevSecOps implementation. Regular training sessions on secure coding practices, threat modeling, and using security tools within the CI/CD pipeline empower teams to take ownership of security. Upskilling ensures that all team members, regardless of role, understand and can apply security principles in their day-to-day activities.

Investing in developer security training will help ensure developers understand the security tools they are using and can interpret the security findings to take appropriate actions for timely resolution. Appoint security champions within the development team to bridge the gap between security and development and integrate security early in the SDLC (“shift left”).

Shift-left Mindset

Promote early and continuous security integration to embed it naturally into workflows.

Promoting a shift-left mindset embeds security early and continuously in the development lifecycle. By addressing vulnerabilities at the earliest stages — design, coding, and testing — organisations can minimise risks and reduce the cost of remediation. This proactive approach ensures security becomes a natural part of workflows, rather than an afterthought.

Careful tool selection and integration planning are crucial. Avoid adopting tools without a clear plan for how they will work together and fit into the existing DevOps process.

Celebrate Wins

Highlight the value of security to foster positive behaviour across teams.

Recognising and celebrating achievements, no matter how small, can foster enthusiasm and reinforce positive behaviors. Highlighting the value of security in delivering trusted, resilient products motivates teams and builds momentum for further improvements. Celebrations also provide an opportunity to reflect on lessons learned and promote a culture of continuous growth.

Final Thouguhts

Transitioning from DevOps to DevSecOps isn’t just a technical shift, but a cultural and organisational one. The challenges teams face are real and significant — from cultural resistance, to tool overload, to security expertise gaps.

By addressing these challenges through leadership support, collaboration, and strategic integration of security practices, organisations can embed security into their development workflows without compromising speed or agility.

What steps is your organisation taking to navigate the shift to DevSecOps? I would like to hear from you in comments!

In the dynamic world of software development, where speed and agility are paramount for competitive business advantage, security cannot be an afterthought.

Taking a shift-left approach in DevSecOps, Static Application Security Testing (SAST) has become a key capability for identifying vulnerabilities in source code before production deployment. However, integrating SAST into CI/CD pipelines presents challenges in balancing performance, agility, accuracy, and developer toil.

Recent advancements in the shift-left movement, such as IDE-integrated SAST plugins and AI enabled tools like GitHub Copilot, have transformed how and when SAST scanning is performed during the software development process. These innovations allow vulnerabilities to be detected earlier and with greater efficiency.

The article explores optimal stages for SAST scanning in CI/CD pipelines and their impact on developer productivity and security outcomes.

SAST Integration Points in CI/CD Pipelines

# Pre-commit Scanning

SAST scanning can be performed at various stages of the CI/CD pipeline. One common approach is pre-commit scanning, where vulnerabilities are identified even before code is committed to the source code repository. This method offers the advantage of immediate feedback, allowing developers to address issues in real time. Fixing vulnerabilities at this stage is highly cost-effective, as it prevents flawed code from entering the repository. However, it can disrupt the developer’s workflow, especially if false positive rates are high or overly intrusive scanning policies are in place.

# Post-commit Scanning

On the other hand, post-commit scanning, performed after code is pushed to the repository, strikes a balance between developer productivity and security. Developers can work uninterrupted, with scans triggered after commits. While this approach provides team-wide visibility into vulnerabilities, the delayed feedback loop may result in rework if critical issues are discovered.

# Build-stage Scanning

For organisations prioritising a secure build process, build-stage scanning ensures only secure code advances through the pipeline. Build stage scanning involves integrating SAST tools with the build process or the CI/CD pipeline to automatically scan code with each build. This approach, though accurate and thorough, can slow down the build process, particularly for large codebases. Performing asynchronous or parallel scans allows decoupling scans from the build process and may provide efficiency gains, but this approach will result in delayed feedback loops.

# Post-build Scanning

This refers to performing security and quality assurance checks after the application has been built but before it is deployed. In this approach, SAST scans and other tasks like unit tests, code quality checks, and FOSS scans are executed in parallel to optimise pipeline efficiency. Post-build parallel SAST scan offers a powerful way to improve CI/CD pipeline efficiency while maintaining robust security and quality checks. By leveraging parallel execution, this approach ensures faster feedback, comprehensive analysis, and scalability for modern software development workflows. However, its success depends on adequate resource provisioning, effective result aggregation, and careful pipeline orchestration to avoid resource contention and delays. For organisations with mature CI/CD practices, post-build parallel scanning can strike a balance between speed, quality, and security.

# Artifact Repo and Pre-production Scanning

A later-stage alternative is artifact repo scanning, which involves analysing compiled code after it has been packaged and published to the artifact repo but before deployment. While this approach cannot replace earlier-stage SAST scans, such as pre-commit or build-time scans, it acts as a crucial safety net to catch vulnerabilities that might have been introduced or missed in earlier stages. For instance, certain issues may only become apparent in the compiled or packaged artifact, such as, vulnerabilities in third-party libraries or dependencies. Artifact-level SAST scanning can effectively detect these vulnerabilities ensuring more secure production deployments.

Vulnerabilities identified at this late stage are often more expensive to fix due to the delayed feedback loop, as they require revisiting earlier stages of the development process to resolve security issues. However, there is a potential for scanning to be mandated at this stage to meet certain regulatory or compliance requirements for highly regulated industries.

Similarly, pre-production scanning uncovers vulnerabilities in a staging environment but introduces delays and higher costs due to the advanced stage of the pipeline.

The Rise of the Shift-left Approach

The traditional SAST integration points, while effective, often struggle to address vulnerabilities early enough to prevent costly fixes. This challenge has driven the rise of the shift-left approach, where security testing begins earlier in the development lifecycle. IDE-integrated SAST plugins are a prime example of this shift. These plugins perform real-time scans within the developer’s Integrated Development Environment (IDE), providing instant feedback as code is written. This early detection not only reduces the risk of vulnerabilities entering the repository but also fosters a security-first mindset among developers.

The benefits of this shift-left approach are significant. By reducing context switching, developers can focus on their work without leaving their IDE to run separate security tools. The immediacy of feedback helps developers understand the root causes of vulnerabilities, improving their secure coding skills over time.

However, this approach is not without its challenges. IDE-integrated tools can sometimes slow down the development environment, particularly for large or complex projects. Moreover, organisations must invest in training developers to effectively use these tools and interpret the results. Another issue could be distraction and reduced focus from the real development work, potentially resulting in alert fatigue. Sometimes, developers may even ignore warnings to meet tight deadlines.

GitHub Copilot and the AI Revolution

A notable addition to the shift-left movement is the introduction of AI-powered tools like GitHub Copilot. While primarily designed as a coding assistant, Copilot is also proving to be a valuable ally in secure coding and early vulnerability detection. By suggesting code snippets that adhere to best practices, Copilot can help developers write secure code from the outset. Its AI model, trained on vast datasets of secure code examples, often pre-empts the need for developers to write potentially vulnerable code in the first place.

In addition to guiding developers toward secure patterns, Copilot can integrate with SAST tools to enhance early vulnerability detection. By combining AI-powered code suggestions with real-time SAST analysis, organisations can significantly reduce the risk of introducing vulnerabilities. This seamless integration not only enhances security but also improves productivity by automating mundane coding tasks and allowing developers to focus on complex problem-solving.

Optimising SAST for Modern Pipelines

To maximise the benefits of SAST in CI/CD pipelines, organisations should adopt a hybrid strategy. Early-stage scanning, powered by IDE plugins and tools like GitHub Copilot, ensures vulnerabilities are caught before they enter the repository. This can be complemented by post-commit and build-stage scans for comprehensive security coverage. Strategies like incremental and full scans, tailoring SAST configurations to reduce false positives, and aligning these with organisational risk thresholds can further streamline the process.

Automation plays a critical role in ensuring developer efficiency. Automating feedback loops and integrating actionable recommendations into the tools developers use daily can significantly reduce the time spent on remediating issues. Moreover, fostering a culture of collaboration and continuous improvement is essential. By training developers on secure coding practices and leveraging AI tools effectively, organisations can turn security from a burden into a productivity enhancer.

Final Thoughts

SAST has become indispensable for securing modern software. With the advent of shift-left approaches and AI-powered tools like GitHub Copilot, organisations now have the means to identify vulnerabilities earlier and more efficiently than ever before. By integrating SAST strategically across multiple stages of the CI/CD pipeline, teams can reduce vulnerabilities, minimise developer toil, and improve overall productivity.

Ultimately, success lies in embracing these innovations while maintaining a balance between security and agility. As technology evolves, so too must our approach to secure software development — ensuring that security becomes an enabler rather than hindrance in delivering high-quality, secure software at speed.

In today’s rapidly evolving cyber landscape, vulnerability management — a practice of identifying, prioritising, and remediating known software vulnerabilities — has been a continuous challenge for organisations.

The issue could be attributed to an increasing number of vulnerabilities identified annually, with a 24.3% increase in 2022 and a 15.6% increase in 2023 over previous years. This rise in published vulnerabilities can be attributed to several factors, such as —

• the digital transformation has made software more ubiquitous;

• the speed of innovation may inadvertently introduce more vulnerabilities; and

• the growing vigilance of the cybersecurity community has exposed more vulnerabilities.

The issue is exacerbated by the shortage of skilled cybersecurity professionals. With increasing awareness of software vulnerabilities and limited capacity to remediate them, vulnerability prioritisation and remediation have become both chronic and acute concerns for organisations attempting to reduce their attack surface.

On one hand, there is a possibility to remediate all vulnerabilities, providing maximum coverage but at the expense of low efficiency. On the other hand, there is a possibility to remediate certain high-risk vulnerabilities, offering higher efficiency but at the risk of missing other high-risk vulnerabilities that may get exploited, thereby exposing an organisation to risk.

A study conducted by the Cyentia Institute has shown that organisations are only able to remediate approximately 10% of vulnerabilities in their environments, regardless of organisation’s size or the maturity of their vulnerability management program. Other studies indicate that while only up to 31% of the published vulnerabilities may have an associated exploit code, on average, fewer than 2% of vulnerabilities are ever weaponized or exploited in the wild.

The Exploit Prediction Scoring System (EPSS), offers a cutting-edge approach to this challenge. This blog post explores what EPSS is, the advantages EPSS offers over other vulnerability scoring systems e.g. Common Vulnerability Scoring System (CVSS), and how it can transform vulnerability management practices by enabling organisations to anticipate threats proactively helping them allocate resources more effectively.

I invite you to dive into the world of EPSS to understand how leveraging real-world data and predictive analytics can enhance your cybersecurity strategy.

What is EPSS?

The Exploit Prediction Scoring System (EPSS) is a data-driven framework managed by the Forum of Incident Response and Security Teams (FIRST), which helps estimate the likelihood that a particular vulnerability will be exploited in the wild within the next 30 days. The goal is to assist organisations in better prioritising their vulnerability remediation efforts.

Unlike traditional vulnerability scoring systems, such as Common Vulnerability Scoring System (CVSS), which assess the severity rating of vulnerabilities based on their inherent characteristics, EPSS uses machine learning to predict the probability of exploitation based on a combination of factors, including real-world exploit data and threat intelligence feeds.

The EPSS model produces probability scores between 0 and 1 (0% and 100%), with higher scores indicating a greater likelihood of exploitation. This system helps organisations prioritise vulnerabilities that are more likely to be exploited, thus enabling more efficient resource allocation towards mitigating critical threats.

EPSS generates daily scores for all published CVEs, reflecting the dynamic nature of cybersecurity threats and underscores the necessity for timely data to facilitate swift action on reducing organisational risk.

EPSS Model — Evolution and Improvements

The EPSS effort began with the publication of a research paper in the Journal of Cybersecurity in July 2020 and the first version of the model was introduced in April 2021.

Since its inception, EPSS has evolved from a simpler logistic regression model to a more complex machine learning model using techniques such as Extreme Gradient Boosting (XGBoost). This evolution reflects ongoing improvements in predictive accuracy and the ability to handle a broader array of data inputs​.

The model has seen three major versions since it first emerged:

1. EPSS v1.0 (April 2021): This initial version used a logistic regression model that integrated data from a limited number of variables. It aimed to predict the likelihood of exploitation within the first year of a vulnerability’s publication. Although the model showed improvements in efficiency and coverage over CVSS, several limitations were highlighted due to the limited data set to train the model.

2. EPSS v2.0 (February 2022): In response to the desire for more robust data and less hands-on scoring by end-users, EPSS v2.0 moved towards a more complex and performant machine learning model, XGBoost. This version employed a gradient boosted tree-based model and significantly increased the number of variables considered — from 16 in the first model to 1,164. This version aimed at predicting the likelihood of exploitation activity within the next 30 days, marking a shift in its predictive focus to a broader and more immediate timeframe, resulting in significant improvements over the previous version.

3. EPSS v3.0 (March 2023): The latest version further refined the predictive capabilities of the system. With continuous updates to the machine-learning model and data sources, EPSS v3.0 can predict with greater efficiency, factoring in a broader array of data points from diverse sources including historical vulnerability data and daily exploit data achieving an overall 82% improvement over v2.0. This version maintains the objective of predicting short-term exploitation risks but with enhanced accuracy and performance.

Each iteration of EPSS has aimed to improve the predictiveness of the system by expanding the data sources used, increasing the sophistication of the machine learning algorithms, and refining the model’s focus to provide more timely and relevant predictions for vulnerability exploitation. The improvements made to the EPSS model across versions, and over the CVSS model, has been demonstrated in the diagram below:

Ref: https://arxiv.org/pdf/2302.14172

The evolution of EPSS reflects a concerted effort to provide a more effective tool for cybersecurity professionals to prioritise vulnerabilities based on the realistic likelihood of being exploited in the wild. This ongoing development signifies FIRST’s commitment to enhancing the practical utility of the EPSS for a comprehensive vulnerability management approach.

EPSS Model — Constituents and Features

The EPSS model incorporates multiple constituents or features, each selected for their relevance in predicting the likelihood of a vulnerability being exploited.

The EPSS model leverages a variety of data sources, including known vulnerabilities from the MITRE CVE list, exploit databases like ExploitDB, and real-world data on exploits. This comprehensive data approach allows EPSS to provide updated and relevant predictions daily​​. The details of the data sources in use are provided in the table below:

Source: https://arxiv.org/pdf/2302.14172

The significance of each constituent is rooted in its ability to provide a different perspective or piece of information about the vulnerability, which collectively enhances the model’s predictive accuracy. Here are the main constituents and their significance:

1. Common Vulnerabilities and Exposures (CVE) Data: This includes the specifics of the vulnerability such as the type, affected systems, keyword description of a vulnerability, and potential impact.

2. Number of Days Since Publication: The age of a CVE is a significant predictor because newer vulnerabilities might attract more attention from attackers and researchers alike, potentially leading to earlier exploits​​. Research indicates that 50% of exploits are published within two weeks, and 13% emerge within a month or so after a new vulnerability is published.

3. Published Exploit Code: The presence of published exploit code in repositories like Metasploit, ExploitDB, or GitHub significantly increases the likelihood of exploitation, as it makes the process easier for attackers by providing them with ready-to-use tools​​. The chances of exploitation in the wild are seven times higher when exploit code is published.

4. Security Scanner Data: Inputs from multiple security scanners about a vulnerability’s detectability and exploitability can provide insights into how easily a vulnerability can be exploited and thus its attractiveness to attackers​​.

5. CVSS Scores: While EPSS and CVSS are different, the CVSS scores, particularly the base metrics, provide insight into the severity and potential impact of a vulnerability. These are used in EPSS to provide context about severity, although EPSS focuses more on the likelihood of exploitation rather than severity​.

6. CPE Data (Common Platform Enumeration): This indicates the specific vendor platforms (software or hardware) affected by the vulnerability. Understanding the platforms involved can help in assessing the potential reach and impact of an exploit, thereby influencing the likelihood of exploitation​​.

7. Common Weakness Enumeration (CWE): The type of weakness associated with a vulnerability helps inform the attractiveness of a vulnerability to adversaries.

8. Machine Learning Models: EPSS has evolved to use advanced machine learning algorithms, specifically a gradient boosted tree model in its latest iteration. These algorithms can handle a large variety of input features and find complex patterns in data that might not be immediately apparent to human analysts. The use of machine learning allows EPSS to continuously learn from new data and improve its predictions over time.

9. Real-world Exploit Data: By incorporating data about actual exploits from various threat intelligence feeds, the model gains a dynamic component that reflects current attack trends and techniques, thus enhancing its relevance and timeliness​.

10. Vendor Products: Specific vendors and their products may be more attractive to attackers due to a specific product’s install base and the associated vulnerabilities.

11. Social Media: Discussions and mentions of a CVE on social media, such as Twitter, may help correlate information about exploitation activity.

The diagram below shows the 30 most significant features demonstrating their influence on the final predictive values produced by the model.

Source: https://arxiv.org/pdf/2302.14172

Each of these components contributes to the overall effectiveness of EPSS by providing comprehensive and nuanced insights into both the nature of the vulnerability and the context in which it exists. This multifaceted approach allows EPSS to offer a probabilistic estimate of a vulnerability being exploited, helping organisations prioritise their security measures more effectively.

Using EPSS for Better Vulnerability Management

Organisations can use EPSS scores, available through FIRST.org’s API and downloadable datasets, to prioritise vulnerabilities that pose a real threat of being exploited. This helps in efficiently directing remediation efforts towards the most critical threats​​.

EPSS can significantly enhance an organisation’s vulnerability management practices in several key ways:

1. Prioritisation of Remediation Efforts: EPSS helps organisations prioritise vulnerabilities based on the likelihood of exploitation rather than just severity. This is crucial because not all high-severity vulnerabilities are exploited with the same frequency or immediacy. By focusing on the likelihood of exploitation, organisations can allocate resources more efficiently, addressing the most pressing threats first​.

2. Resource Allocation: By providing a probability score for each vulnerability, EPSS enables organisations to make informed decisions about where to allocate their limited security resources. This can lead to more effective risk management, as teams can focus on patching vulnerabilities that are most likely to be exploited in the near term​. Using EPSS model, teams can make a trade-off between efficiency and coverage. For example, resource-constrained organisations may focus more on improved ‘efficiency’, whereas the better-resourced organisations with mature vulnerability management programs could focus more on improved ‘coverage’.

3. Enhanced Risk and Security Posture: With EPSS, organisations can enhance their overall risk and security posture by staying ahead of potential threats. Since the system is updated daily with new data, it provides a dynamic and current assessment of the threat landscape, allowing organisations to respond quickly to emerging threats before they are exploited.​ This may even require organisations to update their existing vulnerability management processes to respond to real world threat activity based on dynamic EPSS scores.

At the risk of making this article too long, I will divide it in two parts —

In this part, I have captured the details of the EPSS model, its evolution and history, main components, and how organisations can benefit by incorporating EPSS into their vulnerability management strategies.

In my forthcoming article, I will conduct further analysis on some of the vulnerability management strategies discussed above, along with comparison of EPSS with CVSS, and what EPSS is not. So, stay tuned!

Further Reading

1. Exploit Prediction Scoring System (EPSS), https://www.first.org/epss/

2. Risk Based Prioritization, https://riskbasedprioritization.github.io/epss/Introduction_to_EPSS/

3. Enhancing Vulnerability Prioritization: Data-Driven Exploit Predictions with Community-Driven Insights, 2023, https://arxiv.org/pdf/2302.14172

4. Exploit Prediction Scoring System (EPSS). Digital Threats: Research and Practice 2, no. 3 (2021), https://dl.acm.org/doi/fullHtml/10.1145/3436242

5. Improving vulnerability remediation through better exploit prediction. Journal of Cybersecurity 6, 1 (2020), https://academic.oup.com/cybersecurity/article/6/1/tyaa015/5905457

Anyone working in vulnerability management would have experienced the pain of dealing with ever-growing number of vulnerabilities discovered each year, all vying for their attention for remediation. Teams constantly face challenges in prioritising vulnerabilities, often without a clear understanding of which ones are being exploited in the wild, posing the most immediate threat, and should therefore be addressed first.

This is where the CISA KEV becomes invaluable. In this article, we will delve deeper into understanding what CISA KEV is and how it can help you to strategically improve your vulnerability management practices. We will discuss how by providing a prioritised list of vulnerabilities known to be exploited, CISA KEV helps streamline the focus of vulnerability management teams, enabling them to address the most critical threats first. So lets get started!

What is CISA KEV?

CISA KEV, or Known Exploited Vulnerability Catalogue, launched in November 2021, is a comprehensive list of vulnerabilities known to be exploited in the wild, and is maintained by the Cybersecurity and Infrastructure Security Agency (CISA).

The catalogue serves as an essential resource for cybersecurity professionals and network defenders, enabling them to prioritise remediation on a specific subset of vulnerabilities that pose an immediate threat, based on real-world threat activity. The aim is to help organisations improve their vulnerability management programs and enhance their security posture against known threats.

The KEV catalogue is a key component of the U.S. government’s Binding Operational Directive (BOD) 22–01, Reducing the Significant Risk of Known Exploited Vulnerabilities, issued by CISA. The BOD mandates all federal civilian executive branch (FCEB) agencies to remediate listed vulnerabilities within certain timeframes. While the directive directly applies to FCEB agencies, CISA strongly recommends that all organisations, including those in state, local, tribal, territorial governments, and the private sector, use KEV as part of their vulnerability management strategy to bolster defences against known exploits.

Significance of CISA KEV

With a surge in Common Vulnerabilities and Exposures (CVEs) that has persisted since 2016, and with over 28,000 new CVE entries in the year 2023 alone as shown in the diagram below, cybersecurity teams face a constant challenge of prioritising vulnerabilities for remediation, with an ever-increasing number of vulnerabilities going unresolved at any one time.

The situation gets even worse when ~57% of the vulnerabilities in the National Vulnerability Database (NVD) are marked High or Critical severity without further context or organisational awareness, as per the diagram below, posing further challenges to vulnerability prioritisation and remediation efforts.

Source: https://nvd.nist.gov/general/nvd-dashboard

A number of studies conducted in this space have shown that generally less than 5% of the total number of CVEs get exploited. An analysis conducted by Qualys through their 2023 Vulnerability Threat Landscape study highlighted that less than 1% of all known vulnerabilities were exploited in that year, implying that over 99% of these may have never been exploited, or have a very slight chance of ever being exploited by threat actors. The exploited vulnerabilities are the ones that have a weaponised exploit that is being used by ransomware groups, malwares, or threat actors for exploitation activities.

As per the diagram below, from over 26,000 published vulnerabilities at the time of this study, only 7033 (26.5%) had a PoC, whereas only 206 (0.77%) had been weaponised for exploitation in that year.

Source: Qualys 2023 Threat Landscape study

CISA KEV adds value by highlighting the vulnerabilities that have been weaponised for real-world exploitation. CISA KEV serves as an authoritative source, providing a curated list of vulnerabilities that have been known to be exploited (or are being exploited) in the wild. The principle behind CISA KEV is that while not all vulnerabilities are exploited, those that pose an immediate threat should be given remediation priority.

At the time of this writing, CISA KEV has recorded 1098 vulnerabilities in the catalogue. The catalogue had surpassed 1000 vulnerabilities in September 2023, where CISA had published an article on the progress made since inception and the lessons learned.

By prioritising remediation for vulnerabilities that are known to be exploited, organisations can allocate their limited resources more effectively to address the most pressing threats over others to strategically improve their cybersecurity risk posture.

CISA KEV Criteria

The CISA KEV sends a clear message to all organisations to prioritise remediation on a subset of vulnerabilities that are causing immediate harm based on adversary activity.

CISA uses a rigorous criteria to decide which vulnerabilities to include in the KEV catalogue, as described below:

1. **Assigned CVE ID —**a vulnerability must have a Common Vulnerabilities and Exposures (CVE) ID assigned, so that the organisations can easily identify vulnerabilities that have been added to the KEV catalogue.

2. **Active Exploitation —**there needs to be credible evidence that the vulnerability has been exploited or is under active exploitation. For a vulnerability to be included in the KEV catalogue, an active exploitation means both an attempted exploitation and a successful exploitation. This evidence for exploitation activity must come from reliable sources such as industry partners, security researchers, or government entities. Activities such as scanning, availability of a PoC, or security research on an exploit do not qualify a vulnerability to be included in the catalogue.

3. **Clear Remediation Guidance —**there must be effective mitigation available for the issue, such as a patch or official mitigation guidance. This ensures that the catalogue only includes vulnerabilities for which organisations can take actionable steps to vulnerability remediation.

CISA KEV and CWE Top 10 Mapping

Analysing the KEV catalogue through the lens of Common Weakness Enumeration (CWE) provides further insights into the types of weaknesses that adversaries are most likely to exploit.

In 2023, alongside CWE Top 25, an analysis on entries in the KEV catalogue was conducted and the 2023 CWE Top 10 KEV Weaknesses list was published. By examining the CWE root cause mappings of KEV-listed vulnerabilities, it’s possible to identify common patterns in weaknesses that lead to exploitation.

The pie chart below shows the Top 10 KEV vulnerabilities and their percentages based on the exploitation activity in the wild.

Source: cwe.mitre.org — Percent of 2023 CWE Top 10 KEV Weaknesses by CWE Category.

The treemap chart below demonstrates the individual CWE categories in the Top 10 list. It is worth noting that the top three entries below are related to memory safety, followed by lack of data validation checks.

Source: cwe.mitre.org — 2023 CWE Top 10 KEV Weaknesses List Insights

These insights can help organisations with strategic decision making on where to focus their security improvement efforts and how to develop systems that are secure-by-design.

How Organisations can Leverage CISA KEV

CISA’s KEV catalogue can significantly enhance an organisation’s vulnerability management practices by focusing their efforts on vulnerabilities that pose an immediate and real-world threat.

Here’s how organisations can leverage the KEV catalogue to strategically improve their vulnerability management practices:

1. Prioritisation of Remediation Efforts: The KEV catalogue lists vulnerabilities that have been actively exploited in the wild, which helps organisations prioritise these for remediation over others that may not yet pose an immediate threat. This is especially useful in environments where resources are limited, and not all vulnerabilities can be addressed at once.

2. Informed Decision-Making: By analysing the root causes of the vulnerabilities listed in the KEV catalogue through frameworks like CWE as shown above, organisations can gain insights into common patterns and weaknesses. This knowledge can guide strategic decisions about where to focus security improvement efforts and how to develop more secure systems.

3. Compliance with Directives and Enhancing Security Posture: For U.S. federal agencies and even for private sector organisations, aligning with the KEV catalogue can also be part of compliance with cybersecurity directives. By remediating KEV-listed vulnerabilities, organisations not only improve their security posture but also align with best practices and recommendations from a leading cybersecurity authority.

4. Integration into Vulnerability Management Programs: Organisations can integrate the KEV catalogue into their existing vulnerability management frameworks. The catalogue can serve as a critical input, enabling organisations to prioritise vulnerabilities based on actual exploitation trends. This integration ensures that the vulnerability management process is dynamic and aligned with evolving threat landscapes.

5. Leveraging Community and Vendor Support: The KEV catalogue is recognised and supported by various security communities and vendors, meaning that there are often readily available patches, mitigation advice, and community support for addressing these vulnerabilities. Many commercial vendors have incorporated KEV into their products to highlight vulnerabilities for prioritisation.

6. Enhancing Risk Management: By focusing on vulnerabilities that are known to have been exploited, organisations can better manage their cybersecurity risks. The KEV catalogue helps in identifying and addressing the vulnerabilities that are most likely to be used by adversaries, thus directly contributing to reducing the organisation’s overall risk exposure.

CISA KEV Limitations

While CISA KEV can prove to be a valuable resource for organisations that incorporate it within their vulnerability management practices, it also has certain limitations that organisations need to be aware of.

Some of these limitations may include —

1. Lack of Transparency — CISA has mentioned that it makes use of sources such as industry partners, security researchers, or government entities to identify exploitation activity, however, the process and the resources used to gain access to threat intelligence on vulnerability exploitation activity has not been very transparent.

2. Discrepancy on Coverage — The catalogue has missed certain vulnerabilities that have been demonstrated to be exploited by other studies. e.g. the study form Qualys above shows that CISA KEV had missed 97 vulnerabilities in their catalogue, whereas another study conducted by the Cyentia Institute has highlighted that the KEV catalogue covers a much lower number of vulnerabilities that have been identified to be exploited in the wild. Again, this may come down to the process followed by CISA, or the U.S. government centric focus of the KEV catalogue.

3. Recency Bias — The study conducted by the Cyentia Institute also highlights that there’s a recency bias for vulnerabilities included in the KEV catalogue. What this means is that even though the earliest vulnerability appearing in the catalogue is CVE-2002–0367, the KEV is skewed towards recent vulnerabilities, whereas as per this study, there is much more uniform distribution of vulnerabilities identified over the years that are currently being exploited by threat actors.

4. Static Resource — The KEV catalogue functions as a static resource, meaning once a vulnerability is listed, it remains there indefinitely, even if the exploitation activity has stopped after a while. This could lead to a catalogue filled with outdated entries where no recent exploitation activity has been observed, rendering some listings potentially irrelevant over time. This highlights the need for periodic review to ensure the relevance of vulnerabilities in the catalogue.

5. Prevalence or Frequency of Exploitation — The KEV catalogue does not indicate the prevalence or frequency of exploitation for a given vulnerability; it does not specify whether a vulnerability was exploited just once or if it was targeted hundreds of thousands of times. This lack of detailed information can impact an organisation’s ability to assess the actual risk and urgency associated with each listed vulnerability.

6. Prioritisation within KEV — As the KEV catalogue exceeds 1,000 vulnerabilities, organisations want to understand how to prioritise vulnerabilities within the catalogue. As per CISA, the answer to this question is nuanced and highly dependent on how a vulnerable product is utilised within an organisation’s specific environment. This context-driven approach is crucial for effectively addressing the most critical vulnerabilities as per organisation’s unique operational needs.

Final Thoughts

It goes without doubt that the CISA KEV can act as a valuable resource for any vulnerability management program, empowering organisations to focus on and proactively address the most severe threats. Organisations should seriously consider incorporating KEV into their existing vulnerability management practices to derive immediate benefits and to strategically reduce cybersecurity risks.

Simultaneously, it is crucial for organisations to balance their approach to implementing KEV by recognising its limitations and understanding how to best utilise it within their comprehensive vulnerability management strategy. This will optimise its value while avoiding excessive reliance on the KEV catalogue alone.

Anyone who has worked in cybersecurity or specifically into Vulnerability Management would have come across not only the Common Vulnerabilities and Enumerations (CVE), but also the NIST National Vulnerability Database (NVD).

I had covered about the CVE in my previous article, and the focus of this article is the NVD. I touch upon the origins and evolution of the NVD over time, its significance in vulnerability management, recent developments affecting NVD in the past few weeks, reasons these developments raise concerns, and the industry’s reaction to these events.

What is NVD?

The National Vulnerability Database (NVD) is a standards based vulnerability management database by the U.S. National Institute of Standards and Technology (NIST). The database provides a standardized framework for collecting, assessing, and cataloguing information about security vulnerabilities found in computer hardware and software.

The NVD works closely with the Common Vulnerabilities and Exposures (CVE) system. CVE assigns unique identifiers to vulnerabilities, and the NVD uses these identifiers to provide more detailed information about each vulnerability, including how to protect against it. The database is a crucial tool for cybersecurity professionals, as it helps them stay informed about known vulnerabilities, assess risk to their systems, and take appropriate actions to safeguard against potential threats.

While both NVD and CVE work in close collaboration, these are both separate programs, NVD being managed by the National Institute of Standards and Technology (NIST), and the CVE List being managed by The MITRE Corporation.

Inception and Evolution of NVD

The Information Technology Lab at NIST created Internet Category of Attack Toolkit (ICAT) in 1999, a catalogue of initial attack scripts and vulnerabilities. The ICAT was later rebranded as National Vulnerability Database (NVD) in 2005.

The establishment of NVD was a significant step in improving the cybersecurity infrastructure by providing a standardized and accessible platform for the collection and dissemination of vulnerability data.

NVD enriches the CVE List with risk and impact scoring using the Common Vulnerability Scoring System (CVSS), and provides other references and metadata, such as, patch information, affected products, security checklist reference, and Security Content Automation Protocol (SCAP) mappings.

Since its establishment in 2005, the National Vulnerability Database (NVD) has undergone significant evolution to enhance its capabilities in providing comprehensive vulnerability management data.

By adopting the Security Content Automation Protocol (SCAP) and Common Weakness Enumeration (CWE) since 2007, NVD has been able to automate aspects of vulnerability management and categorize vulnerabilities as specific software or system weaknesses, the adoption of Common Product Enumeration (CPE) since 2008 has helped with the structured naming scheme to identify vulnerable systems, software, and packages. The adoption of various tools and protocols over the years has ensured that the NVD is not just a repository of information but also a tool for proactive cybersecurity management that remains accessible and useful to a global level, beyond just the U.S. government organizations.

The full timeline since inception and evolution over time is published here.

Challenges and Recent Activities

Historically, the NVD has been very consistent on enriching the CVE data as shown in the graph below.

Source: Anchore blog post

The graph illustrates the correlation between the number of CVE IDs published (Green) and the NVD enriched records (Red) between 2005 and 2023.

News announcement— On February 13, 2024, the NVD made the following announcement on their website:

Source: https://nvd.nist.gov/general/news/nvd-program-transition-announcement

and a banner started appearing on the NIST website with the following notice:

Source:

https://nvd.nist.gov/

Upon reviewing the news announcement and the preceding notice above, nothing seemingly unusual stands out to the casual observer. One might infer that NIST is implementing enhancements to the NVD, suggesting that the current disruption could merely be a temporary hiccup before services return to normal.

However, the NVD dashboard published on the NIST website tells a completely different story.

Source: https://nvd.nist.gov/general/nvd-dashboard

The numbers in the table above indicate that the enrichment of CVE data has been ~50% since the beginning of this year, dropped below 50% in February 2024, and has been significantly lower at ~6% in March 2024, marked as ‘Last Month’ and ‘This Month’ respectively in the table above.

The decline in CVE Record enrichment is highlighted further by Anchore engineers in the graph below.

Source: Anchore blog post

The graph clearly indicates that the NVD has not only slowed down but has almost stopped processing the CVE Records since around mid-February 2024. This graph also confirms the numbers in the table above, which is published on the NIST website.

This situation presents a significant concern and should not be taken lightly, especially given the global reliance on the crucial NVD data for understanding vulnerability severity rating (CVSS), vulnerability categorization (CWE), and to identify vulnerable products (CPE) for vulnerability management programs.

Reactions from Industry and Cybersecurity Experts

There has been considerable speculation among industry professionals regarding the current state of NVD, and rightly so, with many cybersecurity experts sharing their analysis of the NVD’s recent data enrichment slowdown.

Many experts have offered their perspectives, seeking to understand the reasons behind the slowdown, and some of the main reasons cited include —

• An explosive growth of cybersecurity vulnerabilities reported each year since 2017 putting strain on resources to conduct analysis.

• Potential budget constraints within NIST affecting the NVD program.

• NIST’s contract coming to an end with the contractor working on the NVD program.

• Potential internal politics around vulnerability standards such as CPE, and PURL etc.

Some of these speculations could be attributed to a perceived lack of transparency and communication from NIST.

The initial comprehensive analysis by Anchore engineers, as mentioned above, prompted further investigations by others in the industry.

For instance, Jay Jacobs from the Cyentia Institute provided an analysis as shown in the images below, comparing the status of the analyzed CVEs to those pending analysis in the NVD for the first three months of 2023 and 2024.

Source: Analysis conducted by Jay Jacobs

As per the images below, Jay Jacobs’ subsequent analysis illustrate the stagnation in the enrichment of four key fields by the NVD for each CVE, with noticeable flattening in the trend lines starting mid-February 2024.

Source: Analysis conducted by Jay Jacobs

The cybersecurity community has responded through the creation of an image below to demonstrate the pivotal role of the NVD in the broader vulnerability management ecosystem.

Source — Patrick Garrity via LinkedIn. Image Origin — xkcd.com

In light of the current challenges, some have proposed transitioning to alternative vulnerability databases, such as the GitHub Advisory Database or the OSV open-source vulnerability database, among potential others. How these alternatives will fill the void left by the NVD remains to be seen.

Moreover, some of the cybersecurity organizations are doing a great job by striving to bridge the gap by providing community-driven resources. An exemplary initiative is VulnCheck NVD++, a free community service that enhances published CVEs with automated CPE enrichment.

Implications to Cybersecurity

For now, the lack of CVE Record enrichment presents a significant challenge as many cybersecurity products depend on the NVD data for identifying vulnerabilities in software products, and providing risk scores for prioritization of vulnerability remediation efforts.

With the new vulnerabilities still being identified and the lack of associated metadata to identify specific vulnerable products, organizations are left in the dark regarding which of their products and systems are affected by particular vulnerabilities, leaving a potential gap in their vulnerability management programs and exposing them to heightened cybersecurity risk.

A Ray of Hope, or is It?

The cause of the recent disruptions to the NVD or the rationale behind the proposed consortium, as mentioned on the NIST website, remains unclear.

At the VulnCon 2024, NIST has finally spoken up and addressed the community, conveying that despite current challenges, the NVD has no plans to shut down and continues to operate, especially in processing critical vulnerabilities in the short term. NIST also revealed plans to establish a consortium, promising to share further details in the forthcoming weeks. However, this announcement did not fully reassure many industry professionals at the conference.

The consortium’s formation and its operational specifics are not shared by NIST at the moment. However, the primary goal seems to be to bring together expertise and resources from various stakeholders to improve the NVD’s capabilities. This collaborative approach could involve industry experts, cybersecurity organizations, and other governmental bodies, leveraging their collective knowledge to address the NVD’s challenges.

This situation raises several questions — such as the nature and the membership of the proposed consortium, the operating model and the modifications it might bring, and the potential delays the cybersecurity industry might face in vulnerability analysis during this transition period.

Dan Loranc from Chainguard has taken a step further by drafting an open letter to the U.S. Congress and Secretary of Commerce, emphasizing the severity of the situation and its repercussions on the cybersecurity industry.

The effectiveness of these initiatives and their eventual impact on the NVD and the broader cybersecurity landscape remains to be seen.

Final Thoughts

This situation raises the question —

“Will the NVD ever be able to recover from the current situation?”

“Have we gone back to the time before the availability of NVD data, and if so, what alternative databases could we depend on should the NVD not recover?”

There are many unresolved questions that demand both short and long-term answers. These are the questions that every cybersecurity professional is currently contemplating and striving to answer.

Only the time will tell how the things turn out! Let’s hope there’s light at the end of the tunnel.

Anyone working in cybersecurity would have come across the term ‘CVE’ more often than they would like to think. For many of us, a CVE ID is a straightforward tag we associate with a specific vulnerability, a routine part of our daily work. Yet, beneath this simplicity lies a complex process, a journey from the identification of a new vulnerability to its public disclosure that benefits the entire cybersecurity community, product vendors, and consumers alike.

In this article, I discuss about why a need for such a system was felt, humble beginnings of the CVE Program, and the evolution of the CVE Program initiative over a period to its current stature. I also explore the roles of various stakeholders involved, and an understanding of the process of assigning CVE IDs to discovered vulnerabilities.

Before delving deeper, let’s start by understanding what is CVE and why is it so important?

What is CVE?

CVE stands for Common Vulnerabilities and Exposures. Each CVE entry in the catalogue, also known as a CVE ID, includes an identification number, a description, and at least one public reference for the vulnerability.

The CVE ID is a unique identifier assigned to each vulnerability, following the format ‘CVE-YYYY-NNNNN’. “YYYY” represents the year the CVE ID was assigned, or the vulnerability was made public, and “NNNNN” is a unique sequence number that can vary in length but is typically four or five digits.

For example, the CVE ID for Log4j vulnerability identified in 2021 is CVE–2021–44228, and the CVE ID for HTTP/2 Rapid Reset vulnerability identified in 2023 is CVE–2023–44487.

Why is CVE Important?

Imagine a case where two or more people are talking about a security vulnerability in a product, or two or more tools are articulating scan results. Before the existence of CVEs, there was no way of knowing if they were talking about the same vulnerability, or at least it will require a lot of manual work to find out if, in fact, they were talking about the same or a different vulnerability.

In the absence of a CVE, how would vendors communicate the patch information to customers to resolve a specific vulnerability in their product. Similarly, how would customers identify an appropriate patch for a vendor product that addresses a specific vulnerability in their system or know which vulnerabilities in their systems have been mitigated. This would result in a disjointed and inefficient approach to vulnerability management, increasing the risk of unresolved security vulnerabilities over time.

All this was prior to 1999 before the CVE Program had originated. The origin of a CVE Program had changed it all.

What is the CVE Program?

The CVE Program initiative had originated out of a need for a standardized system for sharing data about vulnerabilities. In its current form, the program is sponsored by the U.S. Department of Homeland Security (DHS) and the Cybersecurity and Infrastructure Security Agency (CISA) and maintained by the MITRE corporation.

The CVE Program’s mission is to identify, define, and catalogue publicly disclosed cybersecurity vulnerabilities. The program aims to standardize the way the information about security vulnerabilities is shared and addressed, making it easier for everyone involved in cybersecurity to communicate about and manage security threats.

The original concept of the CVE Program was presented by two visionaries from the MITRE Corporation in a seminal white paper titled Towards a Common Enumeration of Vulnerabilities back in January 1999. This seminal work marked the beginning of what would become the CVE List (a catalogue of all published CVE Records) that was officially launched to the public in September 1999. There is one CVE Record for each vulnerability listed in this catalogue, and the initial CVE List contained 321 CVE Records.

Growth in CVE Numbers

From its modest beginnings cataloguing a few hundred vulnerabilities, the cybersecurity community has endorsed the importance of CVE via “CVE-compatible” products and services. Following initial success of the program, CVE has witnessed exponential growth over the years, with the year 2023 alone recording over 28,000 vulnerabilities in the catalogue, as shown in the table below.

Source: cve.org — CVE Records published per year since 1999

A graphical representation of vulnerabilities published over years:

As we can see from above, there has been a big surge in the identified vulnerabilities in recent years. This surge in vulnerabilities may be attributed to several factors:

• With a major focus on speed of innovation, we inadvertently introduce more vulnerabilities into the software we produce, resulting in an explosion of vulnerabilities.

• The growing vigilance and participation of the cybersecurity community, whose collective efforts have brought to light an increasing number of vulnerabilities.

• The digital transformation of society, where software has become ubiquitous, touching every aspect of our lives and, consequently, exposing us to an ever-expanding array of vulnerabilities.

CVE Program Management and Structure

Historically, MITRE populated CVE Records, however, this model was not scalable. Since 2016, the CVE Program has adopted a new federated growth strategy, incorporating new CVE Numbering Authority (CNA) to scale the program. This had led to a significant rise in the reported vulnerabilities in 2017, and the growth in reported vulnerabilities has continued consistently ever since, as is evident from the table and the graph above.

The decentralized approach significantly enhances CVE Program’s coverage, ensures timely and efficient CVE ID assignments by those most familiar with the affected products, bolstering CVE Program’s effectiveness in managing cybersecurity vulnerabilities.

At the time of this writing, the program has grown to have 365 CNAs from 40 countries around the world who have all participated to report over 220,000 CVE Records in the CVE catalogue. The CNAs include vendors, open-source, hosted services, bug-bounty providers, CERTs, researchers, and consortiums, who are authorized to assign CVE IDs and publish CVE Records for vulnerabilities within their distinct and agreed upon scope. The top technology companies, such as, Microsoft, Apple, Google, and others participate in this program. The full list of participating CNAs is available here.

Becoming a CNA is voluntary, however, the participants are required to meet certain minimum criteria to join the program, such as, having a public vulnerability disclosure policy, and agreeing to the CVE Program’s Terms of Use amongst others.

Source: cve.org — CVE program structure

The CVE Program has a hierarchical structure with the CVE Board on top overseeing the CVE Program operations and determining its strategic direction. The program structure also includes CVE Working Groups that are created and administered by the CVE board. There are seven working groups with distinct focus areas that help improve processes, workflows, and other aspects of the program as it continues to grow and expand.

Then we have Top-level Root (both CISA and MITRE) reporting to the CVE board, and managing their own Root, CNAs, and CNA-LR. The CNA-LR is a CNA of Last Resort who is authorized by a Root to assign CVE ID and publish the CVE Record within the Root’s scope for vulnerabilities that are not covered within the scope of another CNA.

This structured, yet flexible organization enables the CVE Program to adapt to the evolving cybersecurity landscape, promoting a collaborative approach to vulnerability management.

CVE Reporting Process

The CVE reporting process involves multiple steps to ensure that vulnerabilities are identified, documented, and communicated effectively.

The assignment of a unique CVE ID marks the first step in acknowledging a vulnerability. Once a new vulnerability is discovered, either by an individual or an organization, it is reported to the CVE Program participants (CNA) and a new CVE ID is requested. This CVE ID is then reserved against the reported vulnerability indicating that a formal record has been established. This helps with coordination and management of vulnerability between stakeholders; however, the details of the vulnerability are not yet made public.

Upon confirmation of the reported vulnerability through the identification of the minimum required data elements, the CVE Record is then published to the CVE List.

According to CVE.org, a CVE entry can be in one of the following three stages at any one time —

1. Reserved— As an initial step, a CNA reserves a CVE ID when a new vulnerability is discovered and reported.

2. Published— When a CNA populates the information associated with a CVE ID, the CVE Record gets published.

3. Rejected— If the CVE ID associated with a CVE Record should no longer be used, the CVE Record is put in a ‘Rejected’ state. The ‘Rejected’ CVE Record remains available on the CVE List so that the users can verify its status and know when it is invalid.

CVE.org has published the information requirements for a CVE Record that must include as a minimum, the affected products, affected or fixed version information, CVE ID, vulnerability type or root cause, and at least one public reference.

Source: CVE Record Lifecycle

CVE Records may be designated as ‘Disputed’ when there is a lack of consensus among involved parties on whether a specific issue or bug constitutes a security vulnerability. This label serves to inform readers, enabling them to determine whether the contested report poses a security risk to their organizational assets.

As a de facto international standard for vulnerability identification, CVE feeds crucial data into the US National Vulnerability Database (NVD), reinforcing its pivotal role in cybersecurity. Once a CVE Record becomes available to NVD, as a first step, the NVD assigns a CVSS score to the published CVE Record.

I will cover more on the role of NVD, highlighting its importance in the whole vulnerability management process in my upcoming article.

Update — Link to the article on NVD:

Is NVD Dead? RIP NVD!
*The Inception and Evolution of NVD, Current Challenges, Future of NVD, and the Way Forward for the Cybersecurity…*medium.com

For many, the concept of software supply chain security has become synonymous to open-source software (OSS) security and the use of Software Bill of Materials (SBOM).

Security vendors offering software composition analysis (SCA) tools are helping to identify vulnerable OSS within our software products by highlighting CVEs. Additionally, many new security start-ups are emerging, offering capabilities to generate and analyse SBOM.

However, there is an important question to ask —

Is securing Open-Source Software (OSS) and generating Software Bill of Materials (SBOMs) sufficient to genuinely address ALL software supply chain security concerns, or if there is more to it?

While there is a heightened awareness of software supply chain security concerns, the definition may vary significantly. If posed with the question, you might get differing answers from everyone asked. While seeking insights from security vendors, their response may align closely with the services they offer.

I firmly believe that software supply chain security is much more than merely performing software composition analysis on open-source software to highlight CVEs and producing Software Bill of Materials **(**SBOM).

So, let’s explore to find out what software supply chain security means in reality and what it entails?

Understanding Software Supply Chains

At a high-level, the software supply chains can be defined as follows —

As per Wikipedia —

“A software supply chain is composed of the components, libraries, tools, and processes used to develop, build, and publish a software artifact.”

RedHat defines software supply chains as follows —

“The software supply chain is made up of everything and everyone that touches your code in the software development lifecycle (SDLC), from application development to the CI/CD pipeline and deployment.

The supply chain includes networks of information about the software, like the components (e.g. infrastructure, hardware, operating systems (OS), cloud services, etc.), the people who wrote them, and the sources they come from, like registries, GitHub repositories, codebases, or other open source projects.”

Getting the definition out of the way, now let’s draw an analogy to a manufacturing process, such as car manufacturing, to better understand software supply chains.

As a manufacturing process involves raw materials, components, equipment, manufacturing processes, people, and distribution channels to create and deliver the final product to end-users, the software supply chains follow a similar pattern involving components, libraries, tools, people, and processes used to develop, build, and publish software artifacts.

The Cloud Native Computing Foundation (CNCF) illustrates how software supply chains closely mirror the manufacturing process as per the diagram below:

Source: CNCF Software Supply Chain Best Practices

Understanding what constitutes a software supply chain is crucial to effectively securing it. If the definition is overly narrow, focusing only on OSS dependencies and generating Software Bill of Materials (SBOMs) to improve transparency and to identify OSS vulnerabilities, it can be challenging to implement a comprehensive security strategy to safeguard the entire supply chain from potential threats.

Considerations for a Comprehensive Software Supply Chain Security Strategy?

While securing OSS could be a significant step forward, it only offers a partial solution to a much bigger and complex problem. So, let’s find out what else do we need to consider as part of an overall strategy to secure software supply chains.

What about the security of third-party vendor products?

Along with OSS security, have you considered the security of third-party vendor products? Yes, I hear you say that these are covered via your vendor assurance programs, but do you have any visibility into what OSS dependencies (both direct and transitive) do they have in the end-product? These products may contain vulnerable or even unsupported OSS dependencies in some cases.

A recent study suggests that software codebases may contain up to 76% of open-source software making it really important for you to understand what OSS components a vendor product has and the security implications.

What about securing developer systems?

Have you considered securing developer accounts, hardening development workstations, or VPN access for remote working? Consider a scenario where threat actors have compromised a developer account through a phishing attack or have exploited a 0-day vulnerability to compromise developer’s machine, allowing them to manipulate the source code in the source code repository to introduce a backdoor in the final product. These are all real threats that demand attention in securing complete software supply chains.

What about securing CI/CD pipelines and development environment?

Have you considered securing your source code manager (SCM), build platform, artifact repositories, secrets management, release and deployment processes? What if a threat actor was able exploit a vulnerability or a weakness in any one of these components or processes to gain direct access to your software development environment and injects malicious code or a backdoor within the final product that gets deployed in production?

The SolarWinds hack involved threat actors being able to compromise the build process introducing a backdoor in one of its products, ultimately providing them access to consumer organizations where the backdoored software was deployed.

What about malicious dependencies and next-generation attacks?

The dangers extend to malicious OSS dependencies. A malicious software is one where threat actors intentionally introduce malicious code or backdoors with the intent of causing harm, whereas a vulnerable software may result from unintentional programming errors introduced by genuine OSS developers.

Threat actors may create packages that seem legitimate but include malicious code or backdoors. They could gain ownership of an open-source package, pose as a contributor, and add harmful code with the hope that it will get approved by package maintainer or an admin.

What about next-generation attacks such as typo-squatting, dependency confusion, repo-jacking, or AI hallucination. These sophisticated tactics could pose serious threats to systems and consuming organizations.

Moreover, these kinds of attacks are not tracked via CVEs, and if not considered may leave a massive gap in your overall software supply chain security strategy.

What about the security of the final product?

Have you considered the security of the end-product itself to ensure that it does not contain security vulnerabilities or has not been altered maliciously?

How about ensuring that your DevSecOps practices include secure coding practices, threat modeling, and security scanning (SAST, DAST, and others) to identify vulnerabilities within the source code as well as the finished product? What about signing artifacts and generating provenance and attestation records and validating these at every stage of the development process and before deployment to production?

An attacker having direct access to your artifact repositories or deployment processes or even the production environment may be able to tamper with software artifacts to inject malicious code or backdoors.

What about the security of runtime and production environment?

Have you considered the security of your runtime or the production environment? What about continuous scanning, monitoring, and improving the transparency of software running in your production environment? A vulnerability in Log4J is a good reminder of having improved transparency of what’s running in your production environment, being able to identify where the vulnerable components are deployed and how much risk do these pose to help you with mitigation efforts.

A question arises, if production even forms part of your software supply chain? If we look at the formal definitions above, the software supply chain goes only up to publishing or deploying a software artifact in production and excludes the production environment itself.

What I believe is since most of the risks are realised in production, it makes sense to extend your software supply chains to production. Even if you have taken all the steps to secure your software supply chains to ensure the security of a released product, it may not remain that way while running in production. New vulnerabilities are identified all the time and may put your application under threat of being compromised.

Every organization operates uniquely, and if certain production processes align with other strategies, such as application security or vulnerability management interlocking security controls, these factors should be considered while determining the components of your software supply chain strategy.

Final Thoughts

To comprehensively secure software supply chains, it is essential to broaden the understanding of security threats and potential attack vectors at every stage within your software supply chains.

Even though Software Bill of Materials (SBOM) is integral to enhancing transparency and security of open-source software within your software ecosystem, it is crucial to understand how it fits in with the overarching software supply chain security strategy.

It’s essential to recognize that supply chain security represents a broader challenge that demands a comprehensive security strategy that goes well beyond open-source software and SBOMs.

In cybersecurity, an appropriate defence can only be established if we know how a system may be attacked.

In my quest for uncovering software supply chain attacks and the attack patterns that adversaries employ to compromise systems and organizations, I have been reviewing frameworks that cover these attack techniques.

In my previous article, I discussed about the MITRE ATT&CK framework.

MITRE ATT&CK Framework and Supply Chain Compromises
*An in-depth review of MITRE ATT&CK framework for ‘supply chain compromises’.*medium.com

The focus of this article is the MITRE CAPEC framework.

One might ask, “Why are there two separate MITRE frameworks?”

That’s a valid question, and it’s worth addressing before we delve into the discussion about the MITRE CAPEC framework.

MITRE ATT&CK vs MITRE CAPEC

It is increasingly important to understand adversary behaviour in order to devise effective mitigation strategies. The two frameworks, ATT&CK and CAPEC, operated by The MITRE Corporation, take different approaches to organize knowledge around adversary behaviours, each focused on a specific set of use-cases.

Common Attack Pattern Enumeration and Classification (CAPEC) is focused on application security and describes common attributes and techniques employed by adversaries to exploit known weaknesses (such as SQL injection or XSS).

Adversarial Tactics, Techniques & Common Knowledge (ATT&CK) is focused on network defence and details attacker tactics, techniques and procedures (TTPs) describing pre- and post-exploit operational phases of an attack (such as persistence, lateral movement and data exfiltration).

CAPEC has provided a detailed comparison of the two frameworks, explaining similarities, differences, relationship between the two, and the role that each plays in cybersecurity.

CAPEC and Supply Chain Attacks

CAPEC provides a publicly available catalogue of known attack patterns helping users understand attacker tactics employed to exploit weaknesses in applications and other cyber-enabled capabilities.

Attack Pattern is a blueprint for a specific type of an attack, with abstracted common attack approaches from known exploits. Attack patterns capture an attacker’s perspective to aid software developers and security practitioners to improve the security profile of a software application.

CAPEC has a dedicated category for supply chain attacks, which is classified under “Domains of Attack” as “Supply Chain — (437)”, where the number in the brackets represents the Attack Pattern ID.

CAPEC describes Supply Chain attack patterns as follows:

Attack patterns within this category focus on the disruption of the supply chain lifecycle by manipulating computer system hardware, software, or services for the purpose of espionage, theft of critical data or technology, or the disruption of mission-critical operations or infrastructure. Supply chain operations are usually multi-national with parts, components, assembly, and delivery occurring across multiple countries offering an attacker multiple points for disruption.

It is evident from the above description that the broader scope and intricate nature of supply chain operations pose challenges in fully comprehending the threat landscape. There could be a multitude of suppliers (both hardware and software) spread across physical geographies, systems, and manufacturing, operational, and distribution processes. All of these could make it difficult to identify weak spots and vulnerabilities within systems and processes posing risks, and to formulate effective mitigation strategies.

The one thing I like about CAPEC framework is that the attack patterns provide detailed information on Likelihood and Severity of attacks, Relationship with other attack vectors, Pre-requisites and Resources required to conduct an attack, Consequences, Mitigation advice, and a mapping with applicable CWE-IDs. All this information helps practitioners with understanding potential risks and devising effective mitigation strategies.

Exploring CAPEC’s Supply Chain Attacks Category

CAPEC offers a systematic approach to categorizing and understanding supply chain attacks. By classifying these attacks into specific attack patterns, CAPEC provides valuable insights to security professionals and organizations to identify, prevent, and mitigate supply chain attacks effectively.

CAPEC categorizes attack patterns into three levels: Meta, Standard, and Detailed. The hierarchical structure helps organize and describe the attack patterns with varying levels of detail and granularity.

The screenshot below lists a subset of CAPEC supply chain attack patterns.

Source: CAPEC

Here’s an overview of each level within the context of supply chain attacks:

#1 — Meta Level:

The Meta level is the top-tier classification under a specific domain in the CAPEC framework. The Meta level provides a broad and conceptual view of supply chain attacks. It helps users identify fundamental themes or commonalities among these attacks, making it easier to navigate the CAPEC framework at a high-level and to understand the broader goals of an attacker.

Meta categories for supply chain attacks include —

• Excavation (116)

• Resource Location Spoofing (154)

• Configuration/Environment Manipulation (176)

• Software Integrity Attack (184)

• Modification During Manufacture (438)

• Manipulation During Distribution (439)

• Hardware Integrity Attack (440)

• Metadata Spoofing (690)

The Meta level supply chain attack patterns describe at a high-level the approaches that attackers can take to compromise software and hardware manufacturing and distribution processes, along with attacks on the integrity of the end product.

#2 — Standard Level:

The Standard level is the second tier of classification in the CAPEC framework. The Standard level adds a layer of detail to the classification, allowing users to explore supply chain attack patterns within a broader Meta category. It helps security professionals and researchers identify specific types of supply chain attacks with similar characteristics and tactics.

For example, at the time of this writing, the Standard categories under “Manipulation During Distribution — (439)” Meta category include —

• Malicious Hardware Component Replacement*— (522)*

• Malicious Software Implanted*— (523)*

• Rogue Integration Procedures*— (524)*

The Standard categories under “Software Integrity Attack — (184)” Meta category include —

• Malicious Software Update — (186)

• Alteration of a Software Update — (669)

The Standard attack patterns may further be divided into Detailed attack patterns based on the granularity required to describe a specific attack pattern. For example, the “Malicious Software Update” category above has further sub-categories as Detailed attack patterns, as described below.

#3 — Detailed Level:

The Detailed level is the most granular level of classification within the CAPEC framework. Attack patterns at this level provide detailed information about specific methods, tactics, prerequisites, and potential mitigations associated with a particular supply chain attack.

The Detailed level serves as a valuable resource for security practitioners and researchers seeking to understand the nuances of a supply chain attack in detail, including how it is executed and how it can be defended against.

At the time of this writing, the Detailed categories under “Malicious Software Update — (186)” Standard category include —

• Malicious Automated Software Update via Redirection*— (187)*

• Malicious Manual Software Update*— (533)*

• Malicious Automated Software Update via Spoofing*— (657)*

I would describe CAPEC’s approach as highly robust in the way it categorizes the attack patterns across various levels. It offers the flexibility to describe an attack at both an abstract level or in greater detail, taking into account the information available and the specific techniques used in executing an attack. This adaptability enables the addition of new attack patterns as they are discovered, whether at the higher Meta level or the more granular Standard or Detailed levels.

Analysis of Software Supply Chain Risks

I dedicated time to compile information from CAPEC’s supply chain attack patterns, presenting it in the form of a table below highlighting risks associated with each pattern outlined in the CAPEC framework.

The table emphasizes specific attack patterns posing greater risks than others, helping to direct your focus towards mitigating supply chain risks effectively.

Summary

In summary, CAPEC’s three-tiered classification system — Meta, Standard, and Detailed levels — provides a hierarchical structure and an organized approach to categorizing and describing supply chain attacks. This structure simplifies the process of locating and identifying relevant attack patterns.

The three levels allow for varying levels of granularity and detail. The Meta level provide a high-level conceptual framework for understanding broad attack themes. The Standard level refine the classification, enabling users to explore specific types of attacks within a broader theme. The Detailed level offers comprehensive information, including attack prerequisites, execution steps, potential mitigations, and real-world examples.

This logical structure and the hierarchical organization assists security professionals, researchers, and organizations in navigating the CAPEC framework and gaining a better understanding of supply chain attacks and associated mitigation strategies in a systematic and consistent manner. Along with this, the assigned risk ratings help with prioritisation efforts.

Related Articles

History and Evolution of Software Supply Chain Attacks
*An exploration of software supply chain threats evolving from initial experiments to sophisticated nation state and APT…*medium.com

MITRE ATT&CK Framework and Supply Chain Compromises
*An in-depth review of MITRE ATT&CK framework for ‘supply chain compromises’.*medium.com

Photo by Miltiadis Fragkidis on Unsplash

In today’s interconnected and digitized world, software plays a pivotal role in virtually every aspect of modern life. It powers the systems that manage critical infrastructure, controls communication networks, and governs the applications that individuals use daily.

As software continues to weave its way into the fabric of society, its security becomes paramount. One crucial facet of safeguarding software integrity is software supply chain security.

Software’s Ubiquity and Dependency

The importance of software supply chain security stems from the sheer ubiquity of software in today’s world. Software is no longer confined to standalone applications on personal computers; it permeates every corner of digital infrastructure, including IoT devices, cloud services, and critical systems involving healthcare, power grids, aviation, smart buildings, and autonomous vehicles. This omnipresence makes the software supply chain a lucrative target for malicious actors seeking to infiltrate systems, steal sensitive data, or disrupt operations at scale.

Moreover, modern software development often involves the integration of third-party components, libraries, and modules, often sourced from open-source repositories. Synopsis reported in their 2023 Open Source Security and Risk Analysis Report that 96% of scanned codebases contained open-source software, whereas, 76% of code in codebases was open-source.

Source: Synopsis 2023 Open Source Security and Risk Analysis Report

This demonstrates our reliance on open-source software ecosystem to produce modern software. While this collaborative approach enhances efficiency, it introduces new risks. Without proper scrutiny, organizations might unknowingly incorporate components with hidden vulnerabilities, leaving their software susceptible to exploitation.

Attack Vectors Multiply

As the software supply chain grows more intricate, so do the attack vectors. Malicious actors can infiltrate the supply chain at any point — inserting malicious code into a seemingly innocent component, compromising a vendor’s infrastructure, or tampering with distribution channels. Each compromised point creates a ripple effect, potentially compromising the security and reliability of the entire software ecosystem.

The Synopsys 2023 Open Source Security and Risk Analysis Report highlighted that the percentage of open-source codebases containing security vulnerabilities remain troublingly high, with 84% codebases containing at least one vulnerability, and 48% of codebases containing high-risk vulnerabilities.

According to the history of attacks recorded by Sonatype since 2017, the attacks show no signs of abating. Sonatype’s 8th Annual State of the Software Supply Chain Report underscores a substantial annual growth rate of 742% in software supply chain attacks.

Source: Sonatype 8th Annual State of the Software Supply Chain Report

Potential Consequences of Compromised Supply Chains

The consequences of compromised software supply chains can be far-reaching and severe. Furthermore, compromised software supply chains can lead to cascading security incidents across industries. A single vulnerable component can be leveraged to exploit multiple organizations, making it difficult to contain the scope of an attack.

The interconnectedness of digital systems amplifies the potential for widespread disruption and increases the complexity of incident response efforts. The exploitation of SolarWinds and Log4j vulnerabilities has demonstrated widespread impact across organizations, industry sectors, and nations.

Financial ramifications are immediate for impacted organizations, as breaches can result in loss of revenue, lawsuits, and regulatory fines. The legal liabilities arising from data breaches or system disruptions can lead to costly legal battles that damage a company’s reputation and bottom line.

Reputational damage is another significant concern. The public has grown increasingly aware of the impact of data breaches and security vulnerabilities. Companies with lax supply chain security practices risk losing customer trust, eroding brand loyalty, and driving users to seek more secure alternatives. Reputational damage can have long-lasting effects, with lasting impacts on revenue and business viability.

In response to the growing threat landscape, regulations are evolving to include stricter requirements for software supply chain security, with the US government issuing an Executive Order on Improving the Nation’s Cybersecurity, and the EU proposing an European Cyber Resilience Act (CRA).

Understanding Software Supply Chain Security

Software supply chain security refers to the protection of software applications throughout their entire lifecycle — from conception and development to distribution and maintenance. It encompasses the complex web of processes, resources, and relationships that contribute to the creation, delivery, and management of software. Software supply chain security addresses the vulnerabilities and threats that can exploit weaknesses in any phase of the software’s lifecycle, potentially compromising the security and reliability of the end product.

I have covered more about software supply chain security in my previous articles:

Software Supply Chain Security — An Introduction
*As organizations have matured their capabilities to protect production systems from cyber threats, attackers have…*medium.com

History and Evolution of Software Supply Chain Attacks
*Software supply chain attacks have been increasing rapidly over the last few years, with some high-profile incidents…*medium.com

Addressing the Need for Security

Given the stakes involved, organizations must prioritize software supply chain security as a fundamental element of their overall cybersecurity strategy. This entails a comprehensive approach that considers security at every stage of the software development lifecycle.

One pivotal aspect of this approach is the integration of security practices into the design and development phases. By baking security into the software’s foundation, organizations can identify and mitigate vulnerabilities early, reducing the likelihood of exploitable weaknesses making their way into the final product. This process includes threat modeling, secure coding practices, and regular code reviews to ensure that software is built with security in mind.

Software Bill of Materials (SBOM) has emerged as a key tool in enhancing software supply chain security. An SBOM is akin to a recipe that lists all the ingredients used in a dish. In the context of software, SBOMs provide a detailed inventory of all components, libraries, and dependencies used in an application. This transparency enhances accountability, facilitates risk assessment, and empowers organizations to respond effectively to emerging threats. SBOMs also facilitate collaboration between stakeholders, helping vendors and customers work together to ensure the security of shared software.

Additionally, various initiatives started by organizations such as NIST (SSDF), OpenSSF (SLSA, Sigstore), OWASP (SCVS), among others, focus on bolstering security and integrity of end-to-end software development and delivery processes. A widespread industry adoption of these may take time as new approaches continue to evolve.

A Holistic Approach

The importance of software supply chain security cannot be overstated in our interconnected digital landscape. The increasing complexity and interdependence of software systems demand a holistic approach to security that encompasses the entire software lifecycle. The potential consequences of supply chain vulnerabilities extend beyond financial losses, affecting reputation, customer trust, and even public safety.

As organizations embrace the imperative to secure their software supply chains, collaboration and knowledge sharing become essential. Industry standards, best practices, and innovative solutions must be developed and shared to build a more resilient software ecosystem. By prioritizing software supply chain security, organizations not only protect their interests but also contribute to a safer digital environment for everyone.

Why NOW?

The urgency to address software supply chain security is more critical than ever. As the software ecosystem expands, embracing third-party components and open-source dependencies, the attack surface grows, amplifying risk.

State governments and regulatory bodies are recognizing the urgency of supply chain security, and imposing stricter compliance requirements. Industry groups have responded by coming up with new standards and frameworks.

The interconnectedness of global supply chains and the rapid pace of development demand proactive measures. The time to act is NOW— to fortify software supply chains, mitigate vulnerabilities, and establish robust security practices. It’s a collective responsibility that encompasses developers, vendors, security experts, and management.

Organizations must prioritize supply chain security to safeguard their assets, maintain consumer trust, and adapt to the evolving threat landscape. As software continues to shape our world, securing its supply chain becomes an imperative to ensure a safer and more reliable digital future.

You’re going for an important meeting and think — “I’m not good enough!”

You’re going to speak on stage and say to yourself — “What if I get caught out?”

You’re having a discussion with a peer group and have this feeling — “I don’t belong here!”

Imposter Syndrome is a feeling that one may have when they undermine their success and doubt their own abilities and accomplishments.

As per English dictionary —

Imposter Syndrome

im·post·er syn·drome [ im-pos-ter sin-drohm ]

anxiety or self-doubt that results from persistently undervaluing one’s competence and active role in achieving success, while falsely attributing one’s accomplishments to luck or other external forces.

A person having these feelings persistently fears of being exposed as a ‘fraud’.

Imposter syndrome can kick in at any time during your career. Even though others may perceive you to be successful and a high achiever, the feeling is only internal to you and no one from the outside can see or feel the same way you do from the inside.

The first time you hear about imposter syndrome, it feels like we are talking about some form of a disease or an illness, at least this is what I thought when I had heard about it for the first time. However, the reality is far from it, and it is not a disease or an illness in any form or shape.

How Imposter Syndrome may impact Security Professionals?

Technology moves at a fast pace and the cybersecurity field is evolving at an even faster rate. This may pose challenges for security professionals in many ways, including —

• Cybersecurity field is vast and therefore it may not be possible for anyone to learn or know everything. There may be people with different skill sets at different levels, however, this may wrongly give someone the impression that others know more than what they do.

• The evolution of new threats and countermeasures can overwhelm security professionals and they may feel that they can’t keep up and start to feel left behind.

• The more you grow in your career, the more you learn about different aspects of cybersecurity. While the breadth of your knowledge grows, it might be difficult to gain an in-depth understanding of everything you do or know, potentially resulting in you believing that you’re not good enough in any of these areas anymore.

• Due to cybersecurity skills shortage, security professionals working in the field may sometimes have to take on extra job responsibilities, resulting in knowledge gaps in areas they may not have worked on before, and this might become overwhelming at times for some people.

• It is common understanding that attackers have to get it right only once to conduct a successful attack, whereas the cybersecurity professionals defending systems and organisations have to get it right 100% of the time. This results in them believing that they need to know it all or else they are not doing their job properly.

All these factors may negatively impact on how cybersecurity professionals see themselves in comparison to others in the field. Sometimes, they may wrongly assume that everyone else knows more than what they do, whereas, in reality, everyone else is most likely in a similar situation as them.

Imposter Syndrome — Imagination vs Reality

Having self-doubt in your abilities and accomplishments can be quite draining and may result in stress and anxiety. This may even result in a burnout if you try to learn it all by yourself and try to be an expert at everything you do in cybersecurity.

I’ve been working in the industry for almost two decades and have learnt a lot over the years, and still feel that there is so much more that I do not know. Not knowing what I do not know should not undermine what I have learnt and accomplished over all these years.

Steps You Can Take to Combat Imposter Syndrome

In hindsight, Imposter Syndrome if taken positively, may help improve your situational awareness and to act as a catalyst to identify opportunities for further professional development.

Understand your strengths and weaknesses. Know your limitations.

Understand your technical strengths and weaknesses based on your previous career history. Understand your career goals, and the expectations from your current role and job responsibilities. Based on this, channelise your energy to improve on areas that align with your short and long-term career goals and job responsibilities.

In cybersecurity, you will always find that someone else is more knowledgeable than you on a particular subject. This is perfectly fine, since they may have different experience than you, and one thing to remember is that no one knows it all. That should not even be the goal since this is only going to result in a burnout. This also helps you to appreciate the accomplishments of other people.

Understand your limitations and accept these, in which case, it might not feel like you will get caught out, since you have already acknowledged and accepted your limitations. Understand who you might reach out to in your peer group for help on subjects that are not aligned with your own core skill sets.

Being mindful will help you to be aware of and to adjust to your surroundings

Someone once told me that you can compare imposter syndrome to ‘jet lag’. This is only a temporary condition while you’re still trying to adjust to your new surroundings.

You may sometimes have these feelings when you’re starting a new job, attending a new seminar or a conference, or interacting with a new peer group for the first time. It is obvious to feel out of place in the beginning. However, take this as an opportunity to understand your new surroundings, identify learning opportunities, and areas for further improvement, which in turn, helps you with your career progression and to become a better security professional.

At the same time, you need to be mindful not to become too complacent once you have adjusted to your new surroundings and not to fall in a ‘know-it-all’ trap and stop learning, which leads us to our next point.

Develop a continuous and focused learning programme

Sometimes, it may feel that the more you learn, the more you find that you know very little. However, use this to your advantage and have a continuous and focused learning programme in place. If you know how much you know and where the gaps are in your knowledge, you can work towards filling those gaps and be more confident about yourself.

The quickest way to shorten your career in cybersecurity is to become complacent and stop learning, and therefore, avoid being in this situation. At the same time, make sure that you don’t get overwhelmed and keep a fine balance between your learning and other work and personal commitments.

Active participation and positive contributions in your profession

Go out of your comfort zone. Easier said than done, however, taking small steps in areas, such as, reading, writing, active participation in peer group discussions, speaking in front of small and familiar group of audience, or participating in a mentorship program (acting as a mentor or a mentee) will help you overcome your negative feelings. You can start small and grow as you feel more confident over a period.

I have recently started writing on Medium and this has helped me improve my understanding of the topics I write about and to identify gaps in my knowledge, which I then go away and research before I write about these.

I have also started a mentorship programme on LinkedIn where I mentor people who are looking to start a career in cybersecurity. This helps me to impart my skills and knowledge to make a positive contribution to the profession and to make a positive difference in someone else’s life, while at the same time, helping me identify gaps in my knowledge and to improve on my own skill sets.

In a nutshell, imposter syndrome may not always be as bad as you might think. Being mindful may prove it to be a blessing in disguise to help you with your professional development.

Uber has been in news for several data breaches that it has endured over the years since 2014. However, something different has happened this time, not only for Uber, but for the whole of the cybersecurity industry.

Joe Sullivan, a former Chief Security Officer (CSO) of Uber was charged with obstruction of proceedings of Federal Trade Commission (FTC) and misprision of felony and was convicted by a San Francisco Federal Court on 5th October 2022.

He faces a prison sentence of 8 years, which is the maximum for these two charges, in connection with his attempted cover-up of a massive data breach that took place in November 2016 involving theft of 57 million records involving Uber drivers’ and customers’ personal information.

It is alleged that Joe Sullivan tried to cover up the breach under Uber’s bug bounty program with HackerOne, by offering $100,000 ransom to hackers as a bug bounty under a non-disclosure agreement and with the assurance that they will delete the compromised data.

The breach was only made public one year later when the Uber’s new CEO, Dara Khosrowshahi, issued a statement about the breach in November 2017. The CEO mentioned in his statement that two of the individuals who led the response to this incident were no longer with the company.

Those who are close to Joe Sullivan say that he is a well-respected CISO with a distinguished track record working as US attorney and holding executive level positions with large and reputed firms including eBay, Paypal, Facebook, Uber and Cloudflare.

It is worth pointing out that only the CISO has been charged in this case, whereas all the other business executives have come out unharmed. There are evidences reported in the news that how Sullivan briefed the then Uber CEO, Travis Kalanick, of the breach, and another one reporting how Sullivan and his security team collaborated closely with legal, communications and other teams within the company as per company’s written policies.

What is evident from the actions taken at the time of breach in November 2016 is that —

1. Hackers were paid a ransom of $100,000 in bitcoins

2. Hackers were later identified in January 2017 and were made to sign a non-disclosure agreement by Uber

Contrary to what has been published, it is evident that these activities may not have been undertaken by the CISO in isolation without any knowledge to anyone else within the organisation. As per some of the news articles, there was involvement from Uber’s executive committee along with legal and communications teams in the handling of this breach. Not to mention that the CISO did all the right things by informing the executive committee and by seeking advice from the legal team as per company’s written policies.

A question arises that how the accountability did not lie with any of the other executive committee members, and how anyone else from the executive committee was not charged? It appears, unfortunately the CISO has been used as a ‘scapegoat’ in this case.

This case highlights many implications for the cybersecurity industry.

Until now, CISOs would generally get fired from their job upon a data breach or for mishandling of this, however, this is the first time a CISO has been convicted of criminal charges for their mishandling of a data breach.

This raises concerns amongst cybersecurity professionals and the questions that are being asked at the moment —

1. Can CISO’s or other security professionals be held responsible and be personally liable for data breaches or the handling of these inappropriately?

2. Are we going to see mass CISO resignations if the CISOs are not ready for the new regime yet, or until they have further clarity on protections that may be offered to them?

3. How will the role of a CISO evolve? Is this case going to help to raise the profile of a CISO (‘Chief’ ISO) in a true ‘executive’ sense within the organisation?

4. The CISO job is tough as it is, now the role will also come with an added baggage of personal liability. Will this reflect in CISO’s compensation package, along with additional legal protection and indemnities?

5. The CISO role has been very broadly defined based on the size of the organisation they are working for. Is this going to affect how the CISO role is defined in the future along with accountabilities?

6. If a CISO can be used as a ‘scapegoat’ as apparently be the case here, will the CISOs put their own interests before their employer’s, i.e. CISO’s becoming more risk averse, potentially adversely impacting an organisation’s growth and progression?

Information security is about risk management, and for the business to remain viable, it is not possible to eliminate the risk from the equation completely. Knowing which risks to treat and which ones to accept in the complex technology world is no easy feat, and a slight error may result in a data breach.

We are really treading on a very thin line making a fine balance between business value proposition and information security. However, cases like this are only going to make security teams’ job harder and may result in an increased friction between the business and the cybersecurity team.

Breaches have happened in the past and breaches will happen again in the future, however, the whole ball game has changed with personal liability and prison sentence on the cards moving forward.

We really have to see how the security industry evolves out of this case!

Related Discussions

October 5, 2022: The Day the Role of the CISO Changed Forever - BSW #280
*In the leadership and communications section, The CISO of Tomorrow Is Stepping Into the Business Spotlight, Why a…*www.scmagazine.com