← Patterns / SP-004

SOA Publication and Location Pattern

Service registries are the phone book of a service-oriented architecture. They publish service endpoints, interface contracts (WSDL, OpenAPI), and metadata that consumers rely on to discover and bind to services at runtime. If an attacker can modify a registry entry, they can redirect traffic to a malicious endpoint, inject a compromised service into a composite workflow, or exfiltrate data by impersonating a legitimate service provider. Protecting the publication and location infrastructure is therefore foundational to SOA integrity. The pattern applies wherever services are registered for discovery -- whether in a traditional UDDI registry, an enterprise service bus catalogue, a modern API gateway, or a Kubernetes service mesh. In each case, the core problem is the same: who is allowed to publish a service definition, who is allowed to discover and consume it, and how do you ensure that what was published has not been tampered with. The pattern draws a trust boundary around the registry itself and the publication lifecycle. Access control is the first layer. Not every developer or system account should be able to publish or modify service entries. Publication rights must be restricted to authorised roles, typically service owners or release managers, with separation of duties between those who develop a service and those who approve its publication. Discovery access may also need restriction: internal-only services should not be visible to external consumers, and sensitive service metadata (security policies, endpoint credentials) must be protected even from authorised consumers who do not need that level of detail. Change control is the second layer. Service interface changes -- adding a new operation, modifying a schema, deprecating a version -- must follow a controlled change management process. Uncontrolled changes to a service contract can break downstream consumers, introduce security vulnerabilities, or violate compliance requirements. Configuration management ensures that every change to a registry entry is tracked, reviewed, and reversible. Certification and assessment provide the third layer. Before a service is published to a production registry, it should be assessed against security standards: input validation, authentication requirements, authorisation model, error handling, and logging. This security certification step prevents vulnerable or non-compliant services from being discoverable and consumable by other systems in the architecture.

Release: 26.02 Authors: Aurelius, Vitruvius Updated: 2026-02-06

Assess

ATT&CK This pattern addresses 295 techniques across 12 tactics View on ATT&CK Matrix →

Click any control badge to view its details. Download SVG

Key Control Areas

Registry Access Control

AC-01 AC-03 AC-05

Access to the service registry must be governed by formal policy (AC-01) that defines who can publish, modify, and discover service entries. Access enforcement (AC-03) ensures that only authorised accounts can write to the registry, with role-based controls distinguishing between service publishers, administrators, and consumers. Separation of duties (AC-05) prevents the same individual from both developing a service and approving its publication to the production registry. In practice, implement RBAC on the registry platform itself, restrict administrative access to a small group, and enforce approval workflows for any new or modified service publication.

Audit and Accountability

AU-01

Every interaction with the service registry must be logged -- publications, modifications, deletions, and discovery queries. Audit policy and procedures (AU-01) should define what events are captured, how long logs are retained, and who reviews them. Registry audit trails are essential for forensic investigation when a service entry is tampered with or when an unauthorised service appears. Modern API gateway platforms provide built-in audit logging; for legacy UDDI registries, ensure that platform-level logging is enabled and forwarded to a central SIEM.

Security Assessment and Certification

CA-01 CA-04

Before a service is published to a production registry, it must undergo security assessment (CA-01) against defined criteria. Security certification (CA-04) formalises this gate: a service that has not passed security testing -- covering input validation, authentication, authorisation, error handling, and transport security -- should not be registerable in production. This prevents vulnerable services from becoming discoverable and consumable. Automate where possible using security scanning in CI/CD pipelines, with the registry publication step gated on a passing security assessment.

Configuration and Change Management

CM-01 CM-03

Service registry entries are configuration items that must be managed under formal change control. Configuration management policy (CM-01) should cover the registry as critical infrastructure. Change control (CM-03) requires that modifications to service definitions -- new versions, schema changes, endpoint updates, deprecations -- follow a documented process with impact analysis, approval, and rollback capability. This is especially important for service contracts that other systems depend on: an uncontrolled breaking change can cascade failures across composite services.

Lifecycle and Engineering Principles

SA-03 SA-08

Services in the registry have a lifecycle -- development, testing, staging, production, deprecation, retirement. Life cycle support (SA-03) ensures that security is addressed at each stage and that deprecated services are removed from the registry in a timely manner to reduce attack surface. Security engineering principles (SA-08) should be applied to the registry architecture itself: defence in depth, least privilege, fail-secure defaults, and separation of production and non-production registries. Do not expose development or test service entries in production discovery; maintain separate registry instances or namespaces per environment.

When to Use

Use this pattern whenever your architecture includes a service registry, API catalogue, or service mesh that mediates discovery between service providers and consumers. It is particularly important when you can distinguish between trusted and untrusted callers -- for example, internal services versus partner-facing APIs. Apply it when services are composed dynamically at runtime based on registry lookups, as a compromised registry entry in this context enables man-in-the-middle attacks at the application layer. Also applicable when regulatory or compliance requirements mandate traceability of service publication and change history.

When NOT to Use

If all potential service consumers are equally trusted and operate within a single, tightly controlled environment with no external exposure, the overhead of full registry protection may not be justified. Very small deployments with a handful of static services and no dynamic discovery may not benefit from the full pattern, though basic access control on service definitions is still recommended. This pattern does not address end-to-end message security between services -- for that, see the SOA Internal Service Usage pattern (SP-005).

Typical Challenges

Enforcing service contracts remains difficult because there are few mature standards for automated contract validation and policy enforcement. While tooling exists for API gateway policy enforcement and contract testing, many organisations still rely on manual review processes that do not scale as the number of services grows. Legacy SOA registries (UDDI) often lack fine-grained access control, making it hard to restrict publication rights without custom development. In microservices architectures, service discovery is often automated through service meshes (Istio, Consul), which introduces new attack surfaces around the mesh control plane. Maintaining consistency between registry entries and actual deployed service configurations is an ongoing operational challenge, particularly when deployments are automated but registry updates are not.

Threat Resistance

This pattern addresses threats from rogue employees who could publish a malicious service to intercept or manipulate transactions, rogue developers who could modify a service endpoint to redirect traffic, and rogue suppliers who could register an unauthorised service impersonating a legitimate provider. It mitigates unauthorised service publication, registry tampering, and service impersonation attacks. The combination of access control, separation of duties, change management, and security certification creates multiple barriers that an attacker must overcome to successfully compromise the service discovery infrastructure. It does not protect against threats at the transport or message layer, which are addressed by complementary patterns.

Assumptions

The service registry is a shared, network-accessible component that multiple systems rely on for service discovery. Service interfaces (WSDL, OpenAPI specs) represent implicit contracts between providers and consumers; modifying them has downstream impact. The organisation uses some form of centralised or federated service catalogue, whether a traditional UDDI registry, API gateway, service mesh, or equivalent. Certificate-based or token-based authentication is available for machine-to-machine registry access.

Developing Areas

API gateways have evolved from simple traffic proxies into full security enforcement points, but the convergence of gateway, service mesh, and API management functionality is creating architectural confusion. Organisations struggle to determine where to enforce authentication, rate limiting, and authorisation when Kong, Istio, and Apigee all offer overlapping capabilities. No industry consensus exists on the optimal layering, leading to either duplicated enforcement (performance overhead) or gaps where each layer assumes the other handles security.
Service mesh security -- particularly mTLS enforcement and fine-grained authorisation policies between services -- is maturing rapidly but operational complexity remains high. Istio, Linkerd, and Consul Connect each take different approaches to certificate lifecycle management, policy definition, and sidecar proxy architecture. Organisations adopting service meshes report 6-12 month learning curves before security policies are consistently enforced, and debugging authentication failures in mesh environments requires specialist skills that are in short supply.
API-first design principles are pushing service discovery complexity into new territory. As organisations expose hundreds of internal APIs through developer portals, the challenge of maintaining accurate, security-classified API catalogues becomes a governance problem rather than a technical one. Emerging API governance platforms attempt to auto-discover APIs from traffic analysis and code repositories, but accuracy rates for security classification remain below 70%, requiring significant manual curation to prevent sensitive internal APIs from being exposed through self-service portals.

Related Patterns

Patterns that operate within or alongside this one. Click any to view.

SP-002 Server Module SP-005 SOA Internal Service Usage SP-008 Public Web Server SP-011 Cloud Computing SP-016 DMZ Module

AC: 3AU: 1CA: 2CM: 2SA: 2

AC-01 Access Control Policies and Procedures

AC-03 Access Enforcement

AC-05 Separation Of Duties

AU-01 Audit And Accountability Policy And Procedures

CA-01 Certification, Accreditation, And Security Assessment Policies And Procedures

CA-04 Security Certification

CM-01 Configuration Management Policy And Procedures

CM-03 Configuration Change Control

SA-03 Life Cycle Support

SA-08 Security Engineering Principles