Safeguard
Application Security•

CWE-1297 Confidential Device Data Exposed to OSAT Vendors

Chips reach assembly and test houses with debug and test modes open. CWE-1297 is about what secrets are still on the part when it gets there.

Safeguard Security Team
3 min read

CWE-1297 is a supply chain weakness in hardware. The product does not adequately protect confidential information on the device from being accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.

How it happens

A chipmaker can do everything in house, from architecture to testing. Or it can architect and design a chip, then outsource the rest to external foundries and test houses. In that second model the device enters the OSAT facility at a vulnerable pre-production stage, when many debug and test modes are accessible.

That forces a degree of trust. Chipmakers often require restrictive non-disclosure agreements. MITRE points out that NDAs do not remove the risk:

  • OSAT vendors likely have many customers, which raises the chance of accidental sharing.
  • The vendor's own IT systems may have a security vulnerability.
  • A malicious insider at the facility could carry out an attack.

Because of that, the chipmaker should minimize the confidential information on the device that the vendor can reach.

What an attacker gains

MITRE rates likelihood as medium and notes that the impact depends on the confidential information exposed. The listed consequences include gaining privileges or assuming identity, bypassing protection mechanisms, executing unauthorized code or commands, and modifying memory, files or directories, along with loss of confidentiality and integrity.

How to find it

Two detection methods are listed. An architecture or design review, rated high, and dynamic analysis with manual results interpretation, rated moderate. Both say the same thing: carry out post-silicon tests to confirm that residual confidential information is not left on parts leaving one facility for another.

A useful routine is to treat every part leaving your control as if it were returned from the field, then try to read secrets out of it using the test interfaces the vendor has.

How to fix it

MITRE rates its mitigation as moderate effectiveness and combines four actions at the architecture and design stage:

  1. Limit what an OSAT vendor can pull through test interfaces to the minimum necessary, both for pre-production and for returned parts.
  2. Design the unlock process so an unlock request unlocks that specific part, not every part in the product line.
  3. Scrub non-volatile memory of confidential information and secrets before handing the device to an OSAT.
  4. Secure all communication between the OSAT facility and the chipmaker.

Quick check

Why not rely on an NDA?

Vendors serve many customers, their IT can have flaws, and insiders can act maliciously. The record says to minimize exposed secrets instead.

What is wrong with a product-line unlock?

If one unlock request opens every part in the line, a single leak affects them all. Per-part unlock limits the damage.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.