(Through the lens of **InternalSoftwarePackage**-based services and our existing security infrastructure)

Many of our services are built on **InternalSoftwarePackage**: a microservice chassis that gives us consistent identity, telemetry, health checks, HTTP clients, and secure-by-default configuration out of the box, and a huge advantage. It means:

  • Authentication is standardized
  • Telemetry is consistent
  • HTTP traffic is observable
  • Configuration follows predictable patterns, enabling baseline security standards to be enforced, audited and maintained at scale.

But even with a strong security baseline, deploying software may change network dependencies, traffic paths, payload sizes or trust boundaries, and these changes can change what the network security infrastructure can see; sometimes in ways that aren’t immediately obvious from code reviews or build pipelines.

This article looks at what changes in network traffic and service-to-service communication when a **InternalSoftwarePackage**-based service evolves, and why those changes matter to our Network Security Team.


**InternalSoftwarePackage** Gives Consistency: But Behaviour Still Changes

From a developer’s point of view, many changes feel somewhat inconsequential, including:

  • Adding a new workflow step in Screen Driver
  • Introducing a new downstream service or API dependency
  • Registering another named HttpClient
  • Enabling Redis output caching
  • Adding Cosmos DB support to a worker
  • Turning on outbound auth for a service-to-service call

From a network perspective, those changes often translate into new traffic patterns, even if everything still follows **InternalSoftwarePackage** conventions.

Network tools don’t know we used:

builder.Add**InternalSoftwarePackage**HttpClient("ExternalApi");

They only see:

  • A service that never made outbound calls before, is now doing so
  • Calls going to a new destination
  • Tokens being requested and attached
  • Payload sizes or request frequencies changing

Example: Adding a New Integration in a “Standard” Way

Let’s say we add a new external service, called from a Screen Driver task in DCQ as follows:

  • Registered via **InternalSoftwarePackage**:HttpClients
  • Uses client credentials
  • Fully instrumented with OpenTelemetry
  • Health-checked and cached

From the application side, this is textbook **InternalSoftwarePackage** usage.

From Network Security’s side, this appears as:

  • A new outbound dependency
  • A new TLS session profile
  • A new authentication flow (token acquisition + API calls)
  • A new steady traffic pattern originating from the DCQ API

This expands the new DCQ service’s blast radius and threat model:

  • If compromised, it can now talk to something it couldn’t before
  • Introduces the potential for lateral movement within the network
  • If misconfigured, there is potential for data leakage
  • If the third party misbehaves, it affects internal stability

None of this means the change is wrong; it just means the risk profile has changed, and the Security team may need to know about it in order to maintain proper oversight and maximise application availability.


Zero Trust Shows Up as “Questions”, Not Blocks

In a zero-trust environment, Network Security assumes:

“Every service is trusted only to do exactly what it needs to do, and nothing more.”

**InternalSoftwarePackage** helps enforce that by:

  • Centralizing identity
  • Standardizing auth flows
  • Making outbound calls explicit via registered HttpClients, so Network Security can anticipate expected traffic and enforce access controls

But when new integrations are added, security systems will naturally ask:

  • Why is this service talking externally now?
  • Is this expected traffic volume?
  • Is this dependency required in all environments?
  • What happens if the token scope is abused?

If those answers aren’t visible ahead of time, the response is often reactive:

  • Alerts
  • Temporary blocks
  • Manual rule adjustments

A small heads-up turns those into intentional allowances instead.


Least Privilege Applies to Connectivity Too

we are already good at least privilege in code:

  • Scoped DI
  • Narrow interfaces
  • Explicit options binding
  • Strong validation

The network equivalent is:

  • Only the services that need connectivity have it
  • Only to the destinations they require
  • Only using the protocols and payloads they expect

When a **InternalSoftwarePackage** service registers a new HTTP client, enables outbound authentication, adds Redis or Cosmos dependencies, or introduces a worker that runs continuously instead of on demand, it is effectively requesting more network privilege, even if no firewall rules were touched directly. Making these changes visible ensures that those privileges remain intentional and tightly controlled.


BFFs and Workflow Engines Change Traffic Shapes

The Screen Driver architectures can be especially interesting from a network perspective.

  • A single user journey can generate:
    • Many short-lived API calls
    • Step transitions with bursty traffic
    • Background tasks firing during state transitions
    • Calls to multiple internal and external services
    • That’s normal for a workflow engine, but it also means:
    • Traffic volume can spike without user count changing
    • Payloads can grow as flow state evolves
    • Retry behaviour can amplify failures
    • When a new step or task is introduced, Network Security may see:
    • Sudden changes in request rate
    • New call chains
    • New downstream dependencies
    • Sharing why that happens helps distinguish expected behaviour from actual abuse or failure.

Observability Helps; But Only If Behaviour Is Understood

**InternalSoftwarePackage** provides us with out-of-the-box distributed traces, metrics, correlation ID’s and structured logs, and this telemetry is invaluable to Network Security in an incident response, but only if the team know and understand which services and dependencies are involved and what is actually “normal and expected” traffic. Without that context, telemetry only tells part of the story.

The Practical Takeaway

**InternalSoftwarePackage** reduces developer complexity and handles common setup and security concerns, but service changes still affect network behaviour and visibility.

Any time a service:

  • Gains a new dependency
  • Changes how often it runs
  • Changes data size, shape or request volume
  • Changes its authentication behaviour

…it changes what Network Security sees and protects.


When should we consider notifying Network Security?

  • New outbound integrations (internal or external)
  • New workers or scheduled processes
  • Significant workflow or traffic-shape changes
  • Auth or token scope changes
  • New data stores or caches that affect traffic patterns

This article shows how deploying or updating **InternalSoftwarePackage**-based services changes both north-south (external) and east-west (internal) traffic. Even standard changes, like adding HTTP clients, enabling Redis caching, or turning on outbound authentication all alter these traffic patterns. Understanding these shifts helps developers notify Network Security of new dependencies, data flows, and authentication paths, supporting least-privilege policies, reducing potential blast radius, and enabling faster, more accurate incident response.