TCP only guarantees that bytes reached the next receive buffer, not that the next application processed or forwarded them. In security pipelines, that means a crash or downstream failure can still lose data after the sender thinks the message is safe. Teams should treat plain TCP as at-most-once, not as a completed delivery guarantee.
Why TCP changes the meaning of “delivered” in a security pipeline
TCP gives you an ordered, retransmitted byte stream between two endpoints, but it does not tell you that the receiving application accepted, processed, queued, or durably stored the message. In a security pipeline, that distinction matters because the transport layer can succeed while the application layer still drops the event, loses state, or crashes before handling it.
That breaks any design that treats a successful send as proof of completed delivery. If the pipeline inserts, filters, enriches, or forwards security data, the sender may advance too early, while the receiver can still fail after the bytes arrive. The result is a false sense of reliability and a blind spot in detection or audit coverage.
TCP also hides a subtle failure mode: connection close, buffer acceptance, or ACKs do not mean the downstream service committed the record. A service restart, overload condition, parser error, queue overflow, or disk failure can still discard data after the network path looked healthy.
Where the delivery assumption breaks in practice
The broken assumption usually shows up at handoff points. A collector may read the bytes but fail before persisting them, a broker may accept them but lose them during failover, or a downstream enrichment service may process only part of the stream and then exit. The sender often cannot distinguish those cases from true completion.
That is why plain TCP is closer to at-most-once semantics than to end-to-end delivery assurance. It can reduce transport loss, but it does not give you acknowledgement that the security event survived application processing. If the pipeline needs durable handling, the design must add an application-level commit, durable queue, idempotent replay, or another explicit acknowledgement boundary.
For engineers, the practical test is simple: ask what event tells the sender that the receiver has actually accepted responsibility for the data. If the answer is only “the socket returned success,” the pipeline is not proving delivery, only transit.
What security teams should design for instead
Security telemetry, alerts, and audit records need a boundary that matches the business expectation, not the transport layer. If losing a single message matters, the pipeline needs durability, retry logic, and a clear deduplication strategy so that retransmission does not create false positives or duplicate incidents.
When the data supports detection or investigation, the safest pattern is to make the receiver write to durable storage before acknowledging success. That shifts the success condition from “bytes arrived” to “bytes are safely committed,” which is the level most teams actually mean when they say delivered.
When the data is high-value or time-sensitive, pipeline exploitation case studies show how quickly an apparently small control failure can become a broader integrity problem. For teams hardening delivery paths, the CI/CD Pipeline Identity Security Guide is useful when the pipeline itself must authenticate securely to downstream services.
For broader delivery integrity, SLSA is relevant because it emphasizes provenance and integrity verification rather than assuming the transport path alone is enough. Where the pipeline is part of software delivery, OWASP SAMM helps teams treat reliability and assurance as part of the development process, not as a transport-layer side effect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Delivery integrity and provenance matter when a pipeline must preserve trusted records. |
| Recommendation — Adopt provenance and integrity checks before treating transmitted artifacts as trustworthy. | ||
| OWASP SAMM | Software Assurance Maturity Model | Pipeline reliability and assurance are development-process concerns, not transport guarantees. |
| Recommendation — Build durable commit and retry behaviour into delivery workflows. | ||
Practitioner Guidance
What to verify: Verify the exact point at which the receiver records a message as committed, not just read. If there is no durable commit or application acknowledgement, treat the path as best-effort transport and expect loss during crash, overload, or failover.
Decision rule: If the event matters for detection, compliance, or incident reconstruction, add an application-level acknowledgement and replay-safe processing model. If duplicates are more dangerous than loss, make the consumer idempotent before you add retries.
What practitioners underestimate: The sender’s success signal is often the weakest part of the chain. The real control question is whether the pipeline can prove end-to-end custody of the record, not whether TCP moved the bytes across the wire.
Practitioner takeaway: Use TCP for transport, but design separately for delivery assurance, because durability, commit, and recovery are application properties, not guarantees of the socket.
Related resources from NHI Mgmt Group
- What breaks when security testing still depends on periodic scans in an AI-driven delivery pipeline?
- What breaks when software teams do not automate application security across the delivery pipeline?
- What breaks when security is added too late in a DevSecOps pipeline?
- What breaks when security teams rely on post-delivery email remediation?