The Priority Gap: When Patchability Does Not Equal Protection

Vulnerability management often fails at the point where security mandates collide with IT operations, creating a Priority Gap between vulnerability discovery and remediation. Adversaries are increasingly exploiting this friction by targeting known vulnerabilities in systems that are technically patchable but operationally sidelined—either because they are deemed too critical to disrupt or too neglected to maintain—until they can be weaponized at scale.

The effectiveness of modern defense is frequently undermined not by a lack of visibility, but by the organizational disconnect between vulnerability detection and remediation. While adversaries have achieved near‑instant velocity through automation, enterprise patching cycles routinely stall when a vulnerability impacts a mission‑critical production system or a fragile legacy application. In these cases, the presence of a patch provides little real protection if the system is viewed as too risky or too complex to modify.

We have entered an era of the unforgiving internet, where the capacity and friction barriers that once shielded neglected systems have vanished. Internet‑wide scanning, exploit commoditization, and automated targeting have collapsed the window between disclosure and exploitation.

In this environment, the gap between being vulnerable and being compromised has narrowed dramatically. AI‑driven automation now enables adversaries to scan the global IP space and operationalize n‑day vulnerabilities within days—and in some cases, hours—of public disclosure. At the same time, many organizations continue to operate internet‑exposed edge appliances with years of unresolved, easily weaponized flaws.

The Application‑Layer (L7)  Blind Spot

A primary driver of the Priority Gap is the disproportionate focus on operating system patching at the expense of the application layer. Servers that are fully patched at the OS level remain critically exposed due to outdated or unmaintained third‑party components. This blind spot extends beyond traditional web applications to specialized operational software and legacy platforms that IT teams may hesitate to update due to uptime requirements, regulatory constraints, or dependencies on continuous data flows. For example attackers continue to target long‑unmaintained platforms such as Zimbra 9 mail servers, where unauthenticated remote code execution vulnerabilities are exploited years after patches became available, simply because the systems were operationally forgotten rather than formally decommissioned.

Consequently, true application patchability requires more than just the availability of a vendor fix; it demands a fundamental shift toward automated software composition analysis and closer collaboration between security mandates and IT operations to bridge the execution gap before flaws are weaponized.

Presentation Layer (L6) - Pretty Interfaces, Ugly Exposures

At the presentation layer, attackers exploit neglected parsing and deserialization logic in application frameworks. Vulnerabilities in components such as UI libraries, serialization handlers, or data transformation engines often persist long after disclosure because they are embedded deep within business applications. These flaws are frequently considered “out of scope” for infrastructure patching, allowing adversaries to weaponize trusted data handling paths.

Session Layer (L5) - The Ghosts of Trust That Never Logged Out

The session layer is increasingly targeted through weaknesses in authentication workflows, state management, and token handling. Long‑lived sessions, reused service tokens, and poorly invalidated credentials create durable access even when perimeter controls are intact. Once compromised, these sessions allow attackers to operate as legitimate users or services, bypassing remediation delays driven by operational caution.

Transport Layer (L4)- Encrypted, Assumed, and Outdated

At the transport layer, organizations often rely on assumed stability of protocols rather than continuous assurance. Misconfigured TLS, outdated crypto libraries, and unpatched transport services remain exposed because upgrades risk breaking compatibility. Adversaries exploit these gaps to intercept, downgrade, or manipulate trusted communications before security teams can safely intervene.

Network Layer (L3) - Discovered Before You Notice

The network layer reflects the collapse of defensive obscurity. Internet‑facing systems with known, patchable flaws are rapidly discovered through automated scanning and global reconnaissance. When routing devices, VPN gateways, or edge appliances are left unpatched due to uptime concerns, the Priority Gap becomes externally visible and quickly exploitable at scale.

Data Link Layer (L2)- The Forgotten Middle

At the data link layer, vulnerabilities in switching infrastructure, virtual networking components, and legacy firmware often persist unnoticed. These systems are perceived as stable and low‑risk, resulting in infrequent patch cycles. Attackers exploit this inertia to pivot laterally, manipulate segmentation boundaries, or establish stealthy internal footholds.

Physical Layer (L1) - Powered On, Forever

While often overlooked, the physical layer underpins every other control. Outdated hardware, unsupported devices, and end‑of‑life platforms frequently remain in operation because replacement is costly or disruptive. Once these assets fall outside patch support, they represent permanent exposure—where vulnerability is both known and unavoidable.

Cutting things short - In the era of the unforgiving internet, vulnerability is no longer defined by exploit availability—but by organizational hesitation.

Turning the Assembly Line into an Attack Path - The Rise of Infrastructure Subversion

Adversaries have increasingly recognized build servers and CI/CD agents as high‑value targets precisely because they are engineered to execute code with elevated privileges and implicit trust. These systems sit at the convergence of source code, secrets, signing keys, and deployment credentials—making them an ideal control point for attackers seeking to influence downstream environments at scale.

By compromising build infrastructure, threat actors can abuse legitimate automation paths to execute malicious logic, alter artifacts, or exfiltrate sensitive credentials—often without triggering traditional security controls. Unlike production environments, build systems are frequently less monitored, more permissive by design, and tightly integrated with developer workflows, creating an attractive attack surface for long‑term, stealthy intrusion. Here is a deep dive into  how CI/CD can be weaponized into an invisible attack path by hackers. 

Why CI/CD is the Top Target

• High-Value Convergence: CI/CD servers hold source code, secrets, signing keys, and deployment credentials in one location.
• Implicit Trust: These systems are designed to automate, meaning they are rarely questioned, allowing malicious actions to blend with routine operations.
• Reduced Visibility: Build infrastructure is often less monitored than production systems, providing a "quieter" environment for long-term stealthy intrusions.
• Unprecedented Scale: A compromise allows for downstream distribution of malicious artifacts to thousands of customers (e.g., the 2026 Axios supply chain breach)

Common Attack Vectors in 2026

• Poisoned Pipeline Execution (PPE): Attackers manipulate repository config files (e.g., .github/workflows) to execute malicious commands within a build agent.
• Credential Harvesting: Attackers use compromised pipeline access to exfiltrate secrets, such as Cloud (AWS, Azure) keys and API tokens, often within minutes.
• Dependency Confusion / Poisoning: Attackers upload malicious packages with similar names to public repositories, forcing build agents to pull the wrong version.
• Compromised Third-Party Actions: Attackers target popular CI/CD marketplace plugins to gain direct access to pipelines. 

Recommendations for Defense

• Hardening Build Agents: Use ephemeral, self-hosted build agents that are destroyed after every build to prevent persistence.
• Secret Management: Never store raw secrets in env variables. Use temporary tokens and secret managers (e.g., Vault, Azure Key Vault).
• Pipeline-as-Code Auditing: Implement strict branch protection rules requiring mandatory code review for any changes to CI/CD configuration files (e.g., Jenkinsfile, .gitlab-ci.yml).
• Minimalist Permissions: Apply the principle of least privilege, ensuring build agents only have access to the resources required for a specific job. 

Goa’s Draft AI Policy 2026: A Promising Step, But the Real Work Lies Ahead

 Artificial Intelligence is no longer just a technology conversation—it is now a governance, risk, and societal conversation. Against this backdrop, the Draft Goa AI Policy 2026 is a timely and welcome development.

At its core, the policy aims to build an inclusive, ethical, and innovation-driven AI ecosystem, while positioning Goa as a forward-looking technology hub. From a Data Protection and Governance perspective, this dual focus—growth with responsibility—is exactly what early-stage AI frameworks should strive for.

What the Policy Gets Right

One of the most encouraging aspects of the draft is that it does not treat AI purely as an economic lever. Yes, there is a strong push around startups, investments, and ecosystem development, but equal emphasis has been placed on public service transformation and citizen impact—including applications in governance, healthcare, and education.

This is important. AI, when deployed in public systems, directly affects people’s lives, rights, and opportunities. Recognizing this early is a sign of a mature policy approach.

The policy also places significant focus on AI skilling and capacity building, which is often overlooked. Building talent pipelines and enabling the workforce ensures that AI adoption is not just top-down but widely distributed.
In many ways, this aligns with the global understanding that AI readiness is as much about people as it is about technology.

Encouraging Signs on Responsible AI

From a governance lens, the introduction of a risk-tiered regulatory approach is particularly noteworthy.
Even though details are still evolving, the intent is clear—AI systems will not be treated uniformly, and higher-risk use cases will require stronger safeguards.

This mirrors global trends. Whether it is the EU AI Act or emerging frameworks elsewhere, risk-based regulation is becoming the norm.

Equally important is the policy’s emphasis on:

• Ethical AI
• Accountability
• Safeguards against misuse

For a draft policy at this stage, acknowledging these dimensions early is a positive signal. It shows that the conversation is not just about “how fast we can adopt AI,” but also about how safely and responsibly we do so.

 

Where the Policy Needs More Depth

That said, the policy is clearly designed as a framework document, and not yet an operational one.

From a DPO perspective, there are a few areas where further clarity will be critical:

1. Data Governance and Privacy Alignment

The policy refers to digital governance and data foundations, but stops short of detailing:

• How personal data used in AI systems will be governed
• Whether risk assessments (like DPIAs) will be required
• How AI and privacy frameworks (such as DPDPA) will intersect

Given that AI systems are inherently data-driven, this will be a crucial area to strengthen.

2. AI Risk Management in Practice

While a risk-tiered approach is mentioned, it is not yet clear:

• How AI systems will be classified into risk categories
• What obligations will apply to high-risk systems
• Whether there will be mandatory assessments, audits, or approvals

Without this, implementation may vary widely across organizations.

 

3. Accountability and Explainability

As AI begins to influence decisions—especially in public services—questions of:

• “Who is accountable?”
• “Can decisions be explained?”

become central.

These are not just technical questions—they are governance and rights-based questions. The policy would benefit from more explicit guidance here.

 

4. Institutional Oversight

Finally, policies are only as effective as their enforcement.
At present, there is limited visibility on:

• Who will oversee AI governance
• How compliance will be monitored
• What enforcement mechanisms will be in place

Defining these structures will be key to ensuring the policy moves from intent to impact.

 

So, Is This the Right Way Forward?

In my view, yes—this is the right way to begin.

The Goa AI Policy does something important: it avoids the extremes of either over-regulation (which stifles innovation) or under-regulation (which ignores risk). Instead, it takes a balanced, principle-led approach.

For a first iteration, this is both pragmatic and aligned with global thinking.

What matters next is execution.

If the policy evolves to include:

• Clear risk and compliance requirements
• Strong alignment with data protection frameworks
• Defined governance and oversight mechanisms

it can become more than just a state initiative—it can serve as a template for responsible AI governance in India.

 

Final Thoughts

AI policies today are not static documents—they are evolving frameworks that must keep pace with technology, regulation, and societal expectations.

The Draft Goa AI Policy 2026 is a good foundation.
It gets the direction right.

Now the focus must shift to depth, clarity, and enforceability—because in AI, intent alone is not enough. It is trust, accountability, and governance that will ultimately determine success.

The Identity Paradox: Why Your Best Password Might Be Letting Hackers In

 

Hey, you've got a super-strong password, two-factor setup, and maybe even a fingerprint scanner. Feels secure, right? But here's the wild truth: identity stuff is still how most big hacks happen.

It's called the Identity Paradox—your login defenses are tougher than ever, but bad guys don't break in anymore. They pretend to be you. Let's break it down, no tech overload.

When "You" Starts Acting Suspicious

Picture this: A hacker logs in looking just like your coworker "Dave from Accounting." No alarms. Why? They stole your login session—like copying your house key while you weren't looking.

Common tricks:

• Cookie Theft: Sneaky malware grabs your browser's "I'm logged in" note. They paste it and... they're you. No password needed!

• Push Notification Spam: Your phone buzzes nonstop with "Approve this login?" You hit yes to make it stop—oops.

• Fake Friends: Sometimes it's a real person with bad intentions, hired to mess things up from inside.

Your front door? Still locked. But now they have a spare key.

Why It's So Hard to Spot

Most security checks just say: "Login good? Check. Two-factor done? Check. Not a weird location? Check." Then... trust city.

Problem is, a good login doesn't mean good intent. Hackers use it to quietly grab files or sneak around—damage done before anyone notices.

The Fix: Watch What Happens After Login

Don't just check the key—watch what they do inside. Make security ongoing, like a smart home camera that learns your habits.

Easy Rules to Live By:

• Assume Risk Always: Even "you" could be fake—keep watching.

• Flag the Odd Stuff: If your marketing buddy suddenly pokes at finance files? That's weird—pause and check.

• Add Everyday Context: Wrong time of day? New device? Question it.

Apps and tools now do this automatically, spotting "not like you" moves in seconds.

Real-Life Example: Imagine logging in at midnight from a coffee shop (unusual for you) and downloading everyone's emails. A smart system flags it: "Hey, this isn't normal—lock it down?"

Fancy logins are a great start, but they're not the whole story. Keep an eye on the behavior—that's what keeps hackers out for real.

Your most trusted login might need the closest watch. Try enabling behavior alerts on your accounts today!

Ever gotten a weird login alert? Share your story in the comments—what's one security habit you're starting?

Under India’s DPDPA: Who Is Liable When an Indian Firm Processes Data for a US Controller?

 

🎯 Short Answer

The US firm (as the Data Fiduciary) is primarily liable under the DPDPA. The Indian firm (as the Data Processor) has no direct statutory liability under the Act — but it can still face contractual liability and indirect exposure if its failures cause the fiduciary to violate the law.

📘 What the Law and Commentary Say

1. DPDPA places primary accountability on the Data Fiduciary

The Act adopts a fiduciary‑centric model:

• The entity that determines purpose and means of processing is the Data Fiduciary (equivalent to GDPR controller).

• The fiduciary is responsible for consent, notices, rights, breach notification, safeguards, and ensuring processor compliance.

This is explicitly stated in legal analyses:

• The DPDP Act “places primary liability on fiduciaries” and processors operate in a subordinate role.

• The Act “attributes sole responsibility upon the main custodians of data… even when the actual processing is undertaken by processors”.

• Unlike GDPR, the DPDPA does not impose direct statutory obligations or penalties on processors.

2. Processors (Indian firm) have obligations only via contract

Processors must:

• Act only on instructions

• Maintain security safeguards

• Restrict sub‑processing

• Cooperate with the fiduciary

• Maintain records

But these obligations are contractual, not statutory. If they fail, the fiduciary is still liable to the Data Protection Board.

3. Cross‑border scenario does NOT change liability

If a US company determines purpose/means, it is the Data Fiduciary, even if it is outside India. DPDPA applies because the processing happens in India.

Thus:

• US firm = Data Fiduciary = legally liable under DPDPA

• Indian firm = Data Processor = no direct liability under DPDPA

4. However, the Indian processor can still be penalized indirectly

If the processor’s negligence causes a breach or non‑compliance:

• The Data Fiduciary is penalized by the Board

• The fiduciary can recover losses contractually (indemnity, breach of DPA, SLA penalties)

So the Indian firm’s exposure is commercial, not regulatory.

🧭 Practical Implication for Your Governance Work

When drafting DPAs for US clients:

• Make the fiduciary’s DPDPA obligations flow down contractually

• Include indemnities, audit rights, breach timelines

• Ensure sub‑processor controls mirror DPDPA expectations

• Clarify that the processor has no independent obligations under DPDPA, but must support the fiduciary’s compliance

This aligns with the Act’s design and the commentary from leading Indian law firms.

NIST SP 800-63 Password Guidance now more relevant

NIST has finally rolled out the next set of updates to NISTSP 800-63.  Hopefully, these new recommendations will change the practice of frequent password resets and contribute to the creation of a more user-friendly and secure password environment.

Credit: Randall Munroe, xkcd.com, CC 2.5

The main ones as of now

1. Elimination of mandatory periodic password changes. “Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.” NIST argues that frequent password resets often lead to weaker passwords and encourage users to make minor, predictable changes. Instead, passwords should only be changed when there’s evidence of compromise.
2. Establish the block list. NIST has emphasized the importance of checking passwords against lists of commonly used or compromised passwords. NIST recommends that organizations maintain an updated blocklist of weak passwords and prevent users from selecting any password on this list.
3. For storing passwords, NIST recommends using salted hashing with a work factor that makes offline attacks computationally expensive. This approach helps protect stored passwords even if a database is compromised.
4. knowledge-based authentication (KBA) no longer recommended (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.” Verifiers and CSPs SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.”
5. Drop the algorithmic complexity song and dance (Complexity Versus Length and uniqueness)
   No more arbitrary password complexity requirements needing mixtures of upper-case letters, lower case letters, special characters, symbols, and numbers. Like frequent password changes, it’s been shown repeatedly that these types of restrictions often result in worse passwords, making it easier for hackers to exploit vulnerabilities.

• Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
• Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
• Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
• Verifiers and CSPs SHOULD accept all printing ASCII characters and the space character in passwords.
• Verifiers and CSPs SHOULD accept Unicode characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.

The Judgement which set the Privacy Wheels rolling - India Supreme Court unanimously recognized privacy as a fundamental right guaranteed by the Constitution

 

On August 24th 2017, the Supreme Court unanimously recognised privacy as a fundamental right guaranteed by the Constitution:

Majority Opinion authored by Justice Chandrachud on behalf of Chief Justice Khehar and Justices Agrawal, Nazeer and himself.

Concurring Opinion authored by Justice Chelameswar.

Concurring Opinion authored by Justice Bobde.

Concurring Opinion authored by Justice Nariman.

Concurring Opinion authored by Justice Kaul.

Concurring Opinion authored by Justice Sapre.

In 2012, Justice K S Puttaswamy, a retired judge of the High Court, filed a writ petition in the Supreme Court challenging the constitutional validity of the Aadhaar scheme introduced by the UPA Government.

On August 11th 2015, a Bench of three judges comprising Justices Chelameswar, Bobde, and C. Nagappan passed an order that a Bench of appropriate strength must examine the correctness of the decisions in M P Sharma v Satish Chandra, District Magistrate, Delhi, 1954 (Eight Judge Bench) and Kharak Singh v State of Uttar Pradesh, 1964 (Six Judge Bench). In particular it ordered that the Court must decide whether we have a fundamental right to privacy.

This matter was first placed before a Five Judge Bench headed by the then Chief Justice Khehar. Subsequently, the matter was referred to a Nine Judge Bench on July 18th 2017. The Bench comprised Chief Justice Khehar and Justices Jasti Chelameshwar, S.A. Bobde, DY Chandrachud, Abdul Nazeer, Nariman, R.K. Agarwal, Abhay Manohar Sapre, and Sanjay Kishan Kaul. Arguments began on July 19th 2017 and concluded on August 2nd 2017.

In a historic decision delivered on August 24th 2017, the Bench unanimously recognised a fundamental right to privacy of every individual guaranteed by the Constitution, within Article 21 in particular and Part III on the whole. The decisions in M.P. Sharma and Kharak Singh were overruled.

Since the 2017 judgment, the fundamental right to privacy has been cited as precedent in various landmark judgments, such as the Navtej Johar and Joseph Shine judgments

The actual judgment makes for an interesting read 

https://github.com/kantakgoa/dpdpa/blob/main/35071_2012_Judgement_24-Aug-2017.pdf

https://main.sci.gov.in/supremecourt/2012/35071/35071_2012_Judgement_24-Aug-2017.pdf