Question and scenario
Design a transparency service for software-supply-chain evidence. A builder can attest to a build environment and artifact digest, a publisher can attest to a release and its source, and an integrator can append test or compliance results. A consumer must verify who signed a statement, whether registration policy passed, and whether a verifiable history receipt exists.
The key boundary is between verifiable records and a business database: the service proves that a statement was registered and checked at a time. It does not replace object storage, a package registry, or a complete dependency resolver.
What the interviewer is testing
Trust boundaries
A strong answer separates issuers, the transparency service, auditors, and relying parties, then states what each party can and cannot prove.
Cryptographic material and history
Explain how signed statements, policy results, an append-only log, and receipts relate. Writing a row to a database alone is not tamper evidence.
Operable governance
Cover key rotation, revocation, duplicate submissions, policy versions, tenant isolation, privacy, and disaster recovery instead of drawing only the write path.
Reliability and scale
Discuss idempotent registration, batch verification, proof reads, cross-region replication, and audit replay for high publication volume and bursty consumers.
Clarifying questions before answering
- Are statements limited to software artifacts, or do they include hardware, models, and deployment environments?
- Is the service run by one organization, or shared by tenants that must verify one another?
- Do consumers require strongly consistent reads, or can they observe “registered but proof not replicated”?
- Which fields are sensitive, and can the public view expose only digests, time, and issuer identifiers?
- Does revocation target a key, a statement, or only a policy decision?
- What are the target throughput, evidence retention period, and cross-region recovery point?
30-second answer framework
“I would split the system into a statement-registration API, policy checker, transparency log, receipt service, and verification SDK. An issuer submits a COSE-signed statement; the service checks a versioned policy and registers it under an idempotency key in an append-only log. The log returns a receipt with an inclusion proof. Consumers verify the signature, log inclusion, policy version, and time offline using the statement, receipt, and audit path. Sensitive fields remain digests or encrypted references. Key rotation and revocation use trust roots and status records, while cross-region replication publishes only after the log and policy results are consistent.”
Step-by-step deep answer
Step 1: Define statements and roles
A statement contains a subject identifier, issuer, type, validity time, policy version, and content digest; the issuer signs it with COSE_Sign1. The transparency service accepts only authenticated issuers and links each statement to a tenant, namespace, and source. Consumers, auditors, and policy administrators have separate permissions.
Step 2: Design registration
The client calls POST /statements with the signed statement, an idempotency key, and a policy hint. The service validates the signature, time window, schema, and issuer status, then evaluates policy. A passing statement is appended to the transparency log. The same content and key return the original receipt; a conflict returns the current registration instead of silently overwriting it.
POST /statements
Idempotency-Key: build-123
Content-Type: application/cbor
{ signedStatement, policyVersion }Step 3: Issue a verifiable receipt
The service creates a receipt containing a log-tree version, leaf digest, proof path, and service signature. A reader verifies the receipt with the service public key, recomputes the statement digest, and checks inclusion. A receipt proves that the service registered and committed to a record at a time; it does not prove the artifact is safe.
Step 4: Handle policy, revocation, and time
A policy is versioned and fixed on each registration record. A later policy does not rewrite the old result; it creates a new assessment statement. Key rotation keeps historical public keys with activation times. Status records can revoke an issuer, key, or statement. Verifiers check statement time, receipt time, and trust-root validity windows.
Step 5: Isolate privacy and tenants
The public log keeps only digests, types, issuer identifiers, and necessary timestamps. Source code, internal domains, and vulnerability details live in encrypted object storage and are referenced by content address. Tenant policy, quotas, and read authorization are enforced at the API; log indexes can be tenant-partitioned while proof formats remain interoperable.
Step 6: Scale, recover, and operate
Shard logs and batch commits on the write path; cache public keys, schemas, and receipts on the read path. Replicate ordered logs and checkpoints across regions. A target region stays read-only until log state, policy results, and key status converge. Track registration success, policy rejection, receipt latency, replication lag, verification failures, and revocation propagation time.
High-quality sample answer
“I would expose a statement-registration API and an offline verification SDK. A build system submits a COSE_Sign1 statement containing an artifact digest, issuer, type, time, and policy version. The service validates the signature and schema, evaluates tenant policy, appends the digest to an append-only transparency log, and returns an inclusion-proof receipt. Registration is idempotent, so retries return the same receipt.
Consumers download the statement, receipt, and trust root and verify the signature, log inclusion, issuer status, and policy version locally. A verification result can become another signed statement, forming a traceable chain. Sensitive content stays behind encrypted references. Historical trust roots remain available after key rotation, and revocation propagates through status statements. Cross-region replication copies ordered log data, checkpoints, and policy results before strong verification reads open. The system proves registration and traceability; it does not replace malware scanning or runtime security.”
Common errors
- Store statements in an editable table → an administrator can rewrite history → use an append-only log, signed receipts, and an independent verifier.
- Treat a transparency receipt as a security verdict → registration does not mean an artifact is vulnerability-free → separate provenance, policy results, and runtime risk.
- Overwrite old records when policy changes → audits cannot reproduce decisions → pin policy versions and append new assessments.
- Rotate only the current key → old statements cannot be verified → retain historical keys and trust roots with activation times.
- Publish every statement field → source and vulnerability metadata leak → expose digests and encrypt sensitive references.
- Let retries create duplicate registrations → unstable history and wasted storage → bind an idempotency key to tenant and signed content.
- Open a replica before proofs converge → incomplete inclusion paths → replicate log, checkpoints, and key status before serving reads.
- Require a central API for every verification → offline audits fail → ship statements, receipts, trust roots, and an offline verifier.
Follow-up questions and responses
Follow-up 1: How do you prove the log did not delete an intermediate record?
Auditors periodically fetch and compare signed checkpoints. Verifiers require monotonic tree size, consistent historical roots, and valid inclusion proofs; a fork stops the log from being trusted.
Follow-up 2: Can receipts from two transparency services verify each other?
They can share statement digests and a standardized receipt format, but each service still signs with its own trust root. Cross-service equivalence needs an additional cross-statement; one service’s public key is not automatically trust for another.
Follow-up 3: How do you revoke an already registered statement?
Keep the original statement and receipt, then append a revocation or risk-status statement. The verifier applies time and policy to decide current acceptance while auditors retain the original registration fact.
Follow-up 4: What happens when registration is unavailable during a release?
The client stores the signed statement and digest locally and labels the release “no transparency receipt yet.” Once restored, it registers with the same idempotency key; missing proof is never presented as verified.
Follow-up 5: How do you keep the log from becoming a privacy leak?
Register the minimum public fields, enforce tenant-level access policy, and use encrypted references. Aggregate time, issuer, and artifact type only as needed while preserving verifiable digests for audits.
Source 1: RFC 9943 SCITT architecture
RFC 9943 defines signed statements, transparency services, receipts, and verifiable data-structure proofs. It also distinguishes registration evidence from artifact storage and dependency resolution. Those boundaries ground the roles, registration flow, and receipt design here.
Source 2: SCITT project overview
The SCITT project describes an auditable, traceable, and verifiable history for supply-chain statements. The tenant verification, policy governance, and regional operations in this answer turn that goal into explicit design trade-offs.
Source 3: Software-engineering interview research
Research on preparing for software-engineering technical interviews emphasizes balancing communication, constraint clarification, and technical reasoning. The clarification questions, short framework, and failure follow-ups are designed to expose those skills rather than reward terminology recall.