The Dangerous Moment Is the State Change: Security Testing for Connected Devices

Posted on by
Reply

The firmware image passes static analysis.

The administrative interface survives a penetration test. The network scan shows only approved services. The mobile application and cloud API have been reviewed. The device enters production with a clean report.

Then the device changes state.

A technician enters maintenance mode. An update loses power halfway through installation. A factory reset prepares the device for a new owner. A recovery process restores an older image. A field engineer connects to a local service interface. A retired device remains registered to a cloud account.

The controls that worked during normal operation may not work the same way during any of those transitions.

That is the testing gap.

Connected-device security is usually evaluated as a collection of components and attack surfaces: firmware, hardware, network services, wireless interfaces, applications, APIs, and cloud infrastructure. Each view matters. None of them, by itself, proves that the product preserves its intended trust state when it is provisioned, updated, interrupted, repaired, reset, transferred, recovered, or retired.

The practical lesson is straightforward:

Device security assurance should test the transitions that change authority, software, data, and operating mode—not only the device’s steady state.

ConfigRvw

A Connected Product Has More Than One Security State

A connected device is not simply secure or insecure.

It moves through states.

The lifecycle may include manufacturing, initial provisioning, normal operation, degraded operation, maintenance, software update, rollback, recovery, factory reset, ownership transfer, and retirement. Some products add calibration, emergency operation, offline modes, safety overrides, diagnostic modes, or vendor-support access.

Each state can change:

  • Which identities are trusted.
  • Which interfaces are reachable.
  • Which code is allowed to run.
  • Which secrets are present.
  • Which data is retained.
  • Which actions are permitted.
  • Which events are logged.
  • Which recovery paths are available.

The current NIST IR 8259 Revision 1, finalized in April 2026, tells IoT product manufacturers to define expected customers and use cases, identify cybersecurity requirements, and plan how the product will support customer risk management. The companion NIST IR 8259A baseline includes device identification, configuration, data protection, logical access to interfaces, secure software update, and cybersecurity-state awareness.

Those capabilities do not exist only during normal operation.

They must remain meaningful while the product changes state.

Steady-State Testing Can Miss Transition Risk

Static firmware analysis can identify exposed secrets, unsafe configurations, vulnerable components, dangerous functions, and other defects inside an image.

Dynamic testing can examine running services, authentication, authorization, input handling, communications, and runtime behavior.

Hardware and interface testing can examine local access paths that a remote network assessment will never see.

Application and API testing can evaluate the services that control the device, store its data, and connect it to other systems.

The OWASP IoT Security Testing Guide reflects this broader reality by organizing testing around the device model, firmware, interfaces, communications, and runtime behavior rather than treating an IoT product as a single web endpoint.

The transition problem appears between those views.

Consider the questions created by an update:

  • Who is allowed to initiate it?
  • How does the device authenticate the update source and verify the image?
  • Can an authorized image be replayed after it should have expired?
  • What happens if power, storage, or connectivity fails halfway through installation?
  • Does rollback return the device to an older but vulnerable state?
  • Are security settings, keys, and logs preserved correctly?
  • Does the device report that it is running a degraded or unexpected version?

Now consider a factory reset:

  • Which user data is removed?
  • Which device identity and cryptographic material remain?
  • Are cloud registrations, mobile-app bindings, or vendor accounts disconnected?
  • Does the reset restore an unsafe default configuration?
  • Can a previous owner or administrator still reach the product?
  • Is the reset event visible to the next operator?

A review that tests only the stable image before and after the transition may miss the condition created during the transition itself.

Build a State-Transition Test Model

Start with a state diagram, not a tool list.

For each important transition, create a compact test record with six fields.

1. Entry condition: What starts the transition?

Identify the command, signal, physical action, scheduled event, fault, account action, or environmental condition that moves the device out of its current state.

Examples include an update request, boot failure, service-button sequence, cloud command, expired certificate, loss of connectivity, storage exhaustion, ownership transfer, or operator decision.

The entry condition should be testable. If the team cannot reproduce the condition safely, it cannot demonstrate how the product behaves when the condition occurs.

2. Authority: Who or what may cause it?

Name every actor that can initiate, approve, block, or complete the transition.

That may include the device owner, local administrator, vendor support team, cloud service, companion application, update-signing system, physical technician, automation service, or another device.

Then test the boundary between those roles.

An identity authorized to read device status should not automatically gain authority to install firmware. A field technician permitted to run diagnostics should not silently become a permanent administrator. A cloud service that can request an update should not be able to bypass the device’s independent verification of the image.

3. Protected state: What changes or persists?

List the assets and security properties that the transition can modify:

  • Firmware and boot components.
  • Configuration and policy.
  • Credentials, keys, certificates, and trust anchors.
  • User, customer, operational, or diagnostic data.
  • Device identity and ownership records.
  • Local and network interfaces.
  • Logging and monitoring state.
  • Safety limits and operating parameters.

Testing should confirm both what changes and what must not change.

4. Failure path: What happens when the transition does not finish normally?

Interrupt the process in a controlled environment.

Remove a dependency. Deny a required authorization. Present an invalid or older image. Exhaust an expected resource. Break connectivity at a defined step. Restart the device while state is being written.

The purpose is not to create theatrical destruction.

It is to learn whether failure moves the product into a secure, observable, and recoverable condition.

5. Evidence: What proves the resulting state?

Define the evidence an operator, customer, assessor, or incident responder can use to determine what happened.

That may include version and integrity measurements, event logs, update records, administrative actions, device-state reports, cloud audit records, tamper indicators, recovery results, or retained forensic artifacts.

If the device cannot explain its own security state, the organization may have to guess whether the transition succeeded.

6. Consequence: What can the new state affect?

Connect the technical result to the product’s real use.

Could the device disclose data, stop a business process, permit unauthorized control, produce incorrect measurements, lose availability, weaken a safety function, or become impossible to recover remotely?

The same technical defect can have very different significance in a consumer accessory, payment device, building controller, medical product, industrial sensor, or safety-related system.

Protect, Detect, and Recover

Device assurance is incomplete if it tests only whether unauthorized change can be prevented.

NIST SP 800-193 organizes platform-firmware resilience around three goals: protect the platform from unauthorized change, detect unauthorized change when it occurs, and recover rapidly and securely.

That sequence is a useful testing standard.

Protect

Verify that only authorized entities can initiate the transition and that the device independently validates the software, configuration, or command it is about to trust.

Test version policy, signing, authorization separation, local access controls, service interfaces, and the protection of keys and trust anchors.

Detect

Verify that the product can recognize and report an incomplete, unauthorized, degraded, or unexpected state.

An update mechanism that rejects a bad image but leaves no useful record may protect the device while weakening incident response. A device that boots a fallback image without reporting the version change may remain operational while concealing a material security event.

Recover

Verify that recovery returns the product to an intended trust state, not merely to an operable state.

The device may power on and still be running an obsolete image, unsafe configuration, untrusted key set, or diagnostic mode. Recovery evidence should show what was restored, which trust decision authorized it, and what follow-up action remains.

Physical Consequence Changes the Test Plan

Connected products can affect more than data.

The final NIST SP 800-82 Revision 3 defines operational technology broadly as programmable systems and devices that interact with the physical environment and emphasizes that security measures must account for performance, reliability, and safety requirements.

That changes how testing should be performed.

An aggressive production scan, unplanned reboot, malformed command, or interrupted update may be acceptable in a disposable lab unit and unacceptable in a live operational process. Some questions should be answered through offline firmware analysis, emulation, configuration review, representative hardware, isolated test networks, or a controlled lab before anyone considers validation in the field.

The test plan should distinguish:

  1. What can be examined without operating the device.
  2. What can be exercised safely on representative hardware.
  3. What requires an isolated system or simulated environment.
  4. What must be validated in the deployed environment under a carefully approved procedure.
  5. What should not be tested actively because the safety or availability consequence is unacceptable.

Restraint is part of good testing.

The objective is not to prove that the assessor can break the device.

It is to produce useful evidence without creating the harm the assessment is supposed to prevent.

Scale Assurance by Consequence and Change

Not every connected product needs the same depth of testing.

A low-consequence, easily replaced device with no sensitive data and minimal authority does not need the same assurance program as a long-lived controller that can alter a physical process.

Set the testing tier using factors such as:

  • Safety and operational consequence.
  • Access to sensitive data or privileged actions.
  • Exposure to untrusted networks, users, or physical access.
  • Authority of local, wireless, cloud, and service interfaces.
  • Complexity of update, rollback, and recovery mechanisms.
  • Dependence on companion applications, APIs, and vendor cloud services.
  • Expected service life and ability to replace the product.
  • Availability of logs, integrity evidence, and emergency recovery.

Then define retest triggers.

A new firmware branch, bootloader, hardware revision, wireless stack, update service, cloud backend, cryptographic design, manufacturing process, or field-service workflow can change the transition model even when the product name remains the same.

The current NIST IR 8259 Revision 1 reinforces this lifecycle view by asking manufacturers to consider customer needs, product requirements, risk mitigations, and the support customers require to use the product securely.

Security testing should follow the product as those conditions change.

Measure Transition Assurance, Not Just Defect Counts

A vulnerability count is useful for remediation tracking.

It does not show whether the product preserves trust across its lifecycle.

More useful measures include:

  • Percentage of high-consequence state transitions represented in the test model.
  • Percentage of update and recovery paths that independently authenticate software and enforce version policy.
  • Percentage of reset, transfer, and retirement paths that remove customer data and obsolete account bindings as designed.
  • Percentage of maintenance and diagnostic actions attributable to a named identity.
  • Percentage of interrupted transitions that produce an observable security-state record.
  • Time required to recover a representative device to a known, supported, and verified state.
  • Number of product changes that altered the threat model but did not trigger security retesting.
  • Percentage of critical transition tests that include the companion application, API, cloud service, and deployed operating assumptions.

One question is especially revealing:

After an update, reset, or recovery fails, can you prove which trust state the device is in?

If the answer depends on a visual guess, undocumented service sequence, or the memory of one engineer, the product may be recoverable without being governable.

What Security Leaders Should Do This Week

Choose one connected product with meaningful business, safety, privacy, or operational consequence.

  1. Draw its states. Include provisioning, normal operation, update, degraded operation, maintenance, recovery, reset, transfer, and retirement where applicable.
  2. Name every transition authority. Identify who or what can initiate, approve, complete, or block each state change.
  3. Map what changes and persists. Include software, configuration, identities, keys, data, interfaces, logging, and cloud bindings.
  4. Choose one failure path. Safely interrupt an update, recovery, reset, or maintenance workflow on representative equipment.
  5. Verify protect, detect, and recover. Confirm that unauthorized change is prevented, abnormal state is visible, and recovery restores a supported trust state.
  6. Connect the result to consequence. Decide what the observed behavior could mean for safety, operations, customers, data, and incident response.
  7. Set the retest triggers. Require reassessment when a material component, interface, update path, backend dependency, or field workflow changes.

A secure firmware image matters.

A hardened interface matters.

A tested API matters.

The product still has to move safely between the states that join those components together.

Test the transition.

That is where the device changes what it trusts.

Put MicroSolved’s Device and Lab Testing Experience to Work

MicroSolved, Inc. can help organizations evaluate industrial, IoT, embedded, and connected products through controlled, evidence-driven security testing.

MSI can assist with:

  • Product threat modeling and state-transition test design.
  • Firmware extraction, static analysis, emulation, and controlled runtime testing.
  • Review of local, network, wireless, service, application, API, and cloud interfaces.
  • Update, rollback, reset, maintenance, recovery, and retirement-path validation.
  • Embedded-device, firmware, AMI, SCADA, segmentation, and tamper-resistance assessment.
  • Test planning for high-availability, safety-sensitive, and critical-infrastructure environments.
  • Prioritized mitigation guidance that connects technical findings to business and operational consequence.

To discuss connected-device, firmware, industrial, or lab testing, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

 

The Leak Is Already Outside: Build an External Exposure Response Loop

Posted on by
Reply

The DLP dashboard is green.

Repository push protection is enabled. The approved file-sharing platform blocks public links. Managed laptops prevent copying sensitive files to removable media. The security team can point to policies, controls, alerts, and training.

Then someone finds a current API key in a public repository.

Or a configuration file in a support forum. A source-code fragment in a paste. An internal hostname in a public issue. A customer data sample in a forgotten cloud share. A credential in a contractor’s fork.

The organization did not see the information leave.

That does not make the exposure less real.

This is the gap between data-loss prevention and external-exposure response. Prevention controls watch selected systems, users, repositories, interfaces, and transfer paths. They are necessary. They are not proof that sensitive information never crossed a path the organization could not see.

The practical lesson is simple:

A data-protection program is incomplete until it can find, neutralize, and learn from sensitive information that is already outside the managed boundary.

SecurityReporting

Prevention Sees the Paths It Controls

Organizations should prevent sensitive data from leaving in the first place.

That includes classifying information, limiting access, using secrets managers, scanning source code, blocking known secret patterns, controlling file sharing, monitoring managed endpoints, and reducing the lifetime and authority of credentials.

The joint CISA and FBI guidance on Product Security Bad Practices identifies hardcoded credentials and secrets in source code as a dangerous practice for products used in critical infrastructure and recommends secrets managers and scanning within the development process.

GitHub provides another useful example. Its secret-security guidance distinguishes push protection, which attempts to stop supported secrets before they enter a repository, from secret scanning and public monitoring, which identify exposures that already exist. GitHub describes public monitoring as visibility into credentials exposed beyond repositories owned by the enterprise.

That distinction matters.

Preventive and detective controls are not interchangeable. One attempts to stop the event. The other assumes prevention can fail and looks for evidence afterward.

Even strong platform controls have scope. GitHub’s own secret-scanning documentation describes supported patterns, pair-matching conditions, legacy-token limitations, large-push conditions, and other cases in which push protection may not detect or block a secret.

That is not an argument against push protection.

It is an argument against treating any point control as proof of absence.

Public repositories are only one possible destination. Sensitive material can also appear in support portals, issue trackers, package artifacts, code forks, shared folders, archived pages, discussion sites, and third-party systems. Some of those channels belong to the organization. Others do not. Some produce useful logs. Others may provide only a timestamp, a URL, and a copy of what was exposed.

The control model must account for both conditions:

  1. Prevent what can be prevented inside managed workflows.
  2. Monitor and respond where prevention cannot provide complete visibility.

Treat External Exposure as Incident Evidence

Finding sensitive material outside the organization is not merely a content-cleanup task.

It may be evidence of an incident.

An exposed credential may still authorize access. A configuration may reveal trust relationships, administrative interfaces, naming conventions, or control gaps. Source code may disclose intellectual property, security assumptions, embedded secrets, or exploitable implementation details. A customer record may trigger privacy, contractual, legal, or regulatory obligations. A seemingly harmless internal identifier may help an attacker improve targeting.

The correct response depends on what the artifact can do, what it reveals, how current it is, and who may have obtained it.

This is why deletion alone is not containment.

Removing a repository, post, attachment, or cached page can reduce continuing exposure. It does not invalidate a credential, erase copies, reverse indexing, identify prior access, or prove that the information was never used.

For secrets, the priority is authority.

The OWASP Secrets Management Cheat Sheet recommends that secrets be revocable, rotated, limited in lifetime and privilege, and supported by lifecycle records that help responders understand who had access and when the secret was used or changed. Stopping the application or deleting the exposed file does not necessarily revoke the credential behind it.

For other data classes, the priority may be different. The organization may need to preserve evidence, restrict further access, notify an owner, assess contractual scope, request removal, investigate misuse, or determine whether the material exists in additional locations.

The external artifact is the beginning of the response question, not the end.

Build the External Exposure Response Loop

A practical external-exposure capability has five stages: discover, classify, neutralize, trace, and learn.

1. Discover: What is visible outside the boundary?

Define the sensitive artifacts the organization cares enough to recognize.

The list may include:

  • Credentials, tokens, private keys, and connection strings.
  • Source code and proprietary algorithms.
  • Device, cloud, application, and network configurations.
  • Internal domains, hostnames, project names, and administrative paths.
  • Customer, employee, regulated, or contractually protected data.
  • Documents carrying distinctive identifiers, watermarks, or structured patterns.

Then define the monitoring scope, frequency, owners, escalation path, and evidence-handling requirements for each class.

No discovery method sees the entire internet. A useful program therefore states its coverage and blind spots explicitly. It distinguishes continuous monitoring from periodic searches, platform-native scanning from broader exposure monitoring, and confirmed findings from possible matches that still require analyst validation.

The goal is not to claim universal visibility.

The goal is to reduce the period during which a consequential exposure remains unknown.

2. Classify: What can the artifact enable?

Do not prioritize solely by how embarrassing the artifact looks.

Classify it by authority, sensitivity, current validity, exploitability, reach, and affected business process.

Ask:

  • Is this an active secret, an expired secret, or a string that only resembles one?
  • What systems, data, funds, or actions could it authorize?
  • Is the artifact complete enough to use, or does it become dangerous when combined with other information?
  • Is the exposed copy current, historical, partial, or modified?
  • Does it contain regulated data, customer information, trade secrets, or security architecture details?
  • Is it publicly accessible, indexed, cached, mirrored, or limited to a narrower audience?
  • Who owns the asset and who has authority to contain it?

The fastest path to a good decision is a prepared owner map. Security should not discover during the incident that nobody knows who can rotate the key, suspend the integration, contact the platform, interpret the contract, or decide whether operations can tolerate emergency change.

3. Neutralize: Remove authority before chasing every copy

If an exposed artifact grants access, invalidate that authority first.

Revoke the token. Rotate the key. Terminate sessions. Disable the account. Restrict the affected interface. Replace the certificate. Narrow the permission. Add temporary monitoring or access controls while the permanent change is implemented.

Then address continuing availability of the artifact through the appropriate channel: delete an owned copy, request removal, use an established takedown process, restrict a share, or work with the platform or third party that hosts it.

Containment order matters.

If responders spend hours removing a public page while the exposed credential remains valid, they are reducing visibility without reducing authority. A downloaded copy can still work.

The neutralization plan must also account for dependencies. Rotating one secret may break applications, vendors, automated jobs, recovery processes, or downstream services. That is a reason to engineer revocation and replacement paths before an incident, not a reason to keep exposed authority alive.

4. Trace: How did it get there, and what happened next?

Once the immediate risk is controlled, reconstruct the path.

Determine:

  • Where the artifact originated.
  • Which person, system, process, or third party handled it.
  • When it became exposed and when the organization discovered it.
  • Whether logs show access, authentication, downloading, reuse, or related activity.
  • Whether the same material exists in forks, mirrors, archives, tickets, backups, chat systems, or build artifacts.
  • Whether similar artifacts were created by the same workflow.
  • Whether an attacker could combine the finding with other public information.

NIST SP 800-61 Rev. 3 frames incident response as part of cybersecurity risk management rather than a stand-alone activity and connects preparation, detection, response, and recovery. External-exposure work should follow the same logic. The team needs enough evidence to reduce immediate impact and improve the system that allowed the exposure.

Tracing must remain proportionate. Not every public identifier justifies a full forensic investigation. Not every old credential remains usable. The classification stage should drive the depth of response.

5. Learn: Which control or assumption failed?

The last stage converts a one-time cleanup into program improvement.

An exposure may reveal:

  • A secret embedded in code because the approved retrieval method was too difficult.
  • A repository that did not inherit the organization’s security configuration.
  • A contractor or vendor using an unmanaged development workflow.
  • Sensitive troubleshooting data copied into a support channel.
  • A DLP policy that covered endpoints but not build logs or cloud collaboration.
  • A credential with excessive privilege or no practical rotation process.
  • A data classification rule that employees could not apply to real work.
  • An alert that reached a mailbox nobody owned.

Fix the common cause, not only the visible artifact.

The question is not simply, “Did we remove it?”

The better question is, “What changed so that the same process is less likely to expose the next artifact?”

Prioritize Authority, Exposure, and Business Consequence

External findings need a decision model.

A useful triage approach considers three dimensions.

Authority

What can the artifact authorize or enable?

An active administrative credential, signing key, production token, or remote-access configuration may require immediate containment. A disabled test credential may require documentation and process correction without the same urgency.

Exposure

Who could obtain it, and for how long?

Public, indexed, and mirrored content has a different exposure profile from a restricted ticket available to a small support team. However, restricted does not mean safe. Third-party access, retention, forwarding, and account compromise still matter.

Business consequence

What could happen if the information is used or disclosed?

Consider system control, customer harm, financial movement, service disruption, regulatory scope, intellectual property, safety, contractual commitments, and reputational impact.

These dimensions prevent two common mistakes.

The first is treating every match as a crisis.

The second is treating a small-looking artifact as harmless when it carries substantial authority.

Measure the Response, Not Just the Number of Hits

Raw alert volume is a weak success measure.

More useful measures include:

  • Time from external publication to discovery.
  • Time from discovery to owner acknowledgement.
  • Time to invalidate active authority.
  • Time to determine the affected systems and data.
  • Percentage of high-impact secrets with a tested emergency rotation path.
  • Percentage of material findings with preserved evidence and documented disposition.
  • Recurrence rate by workflow, business unit, vendor, repository, or artifact type.
  • Percentage of monitoring patterns with a named owner and review date.
  • Number of findings that produced a control, process, or architecture improvement.
  • Percentage of high-risk exposures for which misuse could be assessed from available logs.

One metric deserves special attention:

How long does it take to make a discovered artifact harmless?

Discovery creates the opportunity to respond.

Neutralization changes the risk.

Where ClawBack Fits

MicroSolved currently positions ClawBack™ as a data-leak detection capability supporting exposure monitoring, advisory retainers, and vCISO relationships, with evidence that can support response conversations.

That is the right place for external-exposure monitoring in the operating model.

Its job is not to replace DLP, repository controls, secrets management, identity governance, incident response, or legal and privacy review. It helps close the visibility gap between what internal controls observed and what may be visible outside the organization.

The value of a finding depends on the process around it:

  • What classes of information are in scope?
  • Which sources and channels are monitored?
  • How are possible matches validated?
  • Who owns each artifact class?
  • What evidence is preserved?
  • What requires immediate escalation?
  • How will credentials be revoked, files removed, and downstream impact assessed?
  • How will lessons feed back into prevention?

ClawBack should therefore be treated as part of an exposure-response capability, not as an isolated alert feed.

What Security Leaders Should Do This Week

Choose one artifact class with meaningful business consequence: production API keys, administrative credentials, network configurations, source code, customer records, or another clearly owned data set.

Then run this exercise:

  1. Define what a recognizable exposure looks like. Identify patterns, identifiers, owners, and likely external channels.
  2. Document current coverage. Record which preventive and detective controls can see the artifact, and which paths remain outside their scope.
  3. Prepare the owner map. Name the people who can classify the finding, revoke authority, approve operational impact, preserve evidence, request removal, and assess notification obligations.
  4. Test neutralization. Measure how long it takes to revoke or replace the artifact without creating uncontrolled business disruption.
  5. Simulate one discovery. Walk the finding through discover, classify, neutralize, trace, and learn.
  6. Verify the logs. Confirm that responders can determine whether the artifact was used and which systems were affected.
  7. Close one recurring path. Improve the workflow most likely to produce the same exposure again.

Data-loss prevention is important.

Secret scanning is important.

Repository protection is important.

None of them can prove that sensitive information is absent from every external place the organization does not control.

Build the response loop for the moment the leak is already outside.

Put External Exposure Monitoring Into the Security Program

MicroSolved, Inc. can help organizations:

  • Define external-exposure monitoring requirements for credentials, source code, configurations, and other sensitive artifacts.
  • Integrate ClawBack findings into vCISO, advisory, and incident-response workflows.
  • Build artifact classification, ownership, escalation, and evidence-handling processes.
  • Test credential revocation, session termination, takedown, and downstream-impact procedures.
  • Review DLP, repository, secrets-management, vendor, and cloud-collaboration control gaps.
  • Turn recurring exposures into practical control and process improvements.

To discuss ClawBack or an external-exposure response review, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

 

The Network Is the Configuration: Why Device-by-Device Reviews Miss Systemic Risk

Posted on by
Reply

The firewall passes its review.

The router matches its hardening guide. The core switches have approved templates. The VPN concentrator is supported. The wireless controllers have current settings. Each team can point to a device, a checklist, and a green result.

The environment can still be unsafe.

A route may bypass the intended boundary. An emergency access rule may have become permanent. Two business units may use different authentication sources for the same administrative function. A management interface may be reachable from the wrong zone. Logging may be enabled on the newest devices and absent from the oldest ones. A segmentation design may exist in a diagram without being enforced consistently across the equipment that implements it.

The failure is not necessarily inside one device.

It lives in the relationships among them.

That is the limitation of device-by-device configuration review. It can tell an organization whether individual components satisfy selected requirements. It may not show whether the combined environment still implements the security architecture the organization believes it has.

The practical lesson is straightforward:

Configuration assurance should prove the effective state of the environment, not merely the acceptability of isolated devices.

Nodes

The Network Does Not Experience Controls One Device at a Time

Standards correctly require secure configuration practices.

NIST Special Publication 800-128 describes security-focused configuration management as the work of managing and monitoring system configurations to support business functionality while reducing organizational risk. The CIS Controls call for maintained secure configurations across enterprise assets and software, while CIS Control 12 focuses on actively managing network devices so vulnerable services and access points do not become attacker paths.

Those practices create necessary baselines. The harder question is whether the baselines compose into the intended result.

Consider segmentation.

One firewall may correctly restrict traffic between two zones. That does not prove there is no alternate route through another firewall, a cloud connection, a VPN profile, a shared management network, a wireless bridge, or a vendor access path. Each component can look reasonable in isolation while the system still permits a path the architecture was intended to prevent.

The same problem appears with authentication, logging, encryption, administrative access, name resolution, and trusted-host definitions. The control is often distributed across products, vendors, versions, teams, and locations. Its effectiveness depends on consistency and relationships.

A useful review must therefore ask two different questions:

  1. Is this configuration acceptable for this component?
  2. Does this collection of configurations enforce the intended control across the environment?

The first question finds local defects.

The second finds systemic risk.

Separate Intent, Implementation, and Effective State

Most organizations have at least three versions of their network.

The intended network

This is the architecture described in diagrams, standards, policies, design documents, approved data flows, and segmentation plans. It explains what the organization expects the environment to do.

The implemented network

This is the collection of current device and application configurations: routes, access-control lists, VLANs, authentication servers, management interfaces, DNS settings, logging destinations, encryption choices, firmware versions, and exceptions.

The effective network

This is what those configurations permit, deny, trust, expose, record, and connect when they operate together.

The three should agree. They often diverge because organizations change continuously. Acquisitions introduce new standards. Cloud services create new paths. Vendors receive temporary access. Emergency rules survive the event that created them. Hardware generations overlap. Different teams interpret the same policy differently. A compensating control exists in one region and is assumed to exist everywhere.

The September 2026 edition of the Australian Signals Directorate’s Information Security Manual guidance for networking illustrates the breadth of evidence involved. It calls for maintained network documentation that includes high-level and logical diagrams as well as device settings for critical systems and network equipment. It also addresses segmentation, dedicated management networks, device hardening, and logging of security-relevant events, including configuration changes.

No single configuration file proves all of that.

Assurance comes from reconciling intent, implementation, and effective state across the devices that jointly create the control.

Build a Configuration Evidence Model

An environment-wide review needs more than a larger pile of device reports. It needs a model that preserves the relationships among assets, settings, policies, and exceptions.

A practical configuration evidence model has five views.

1. Inventory view: What is represented?

Identify the devices, applications, virtual appliances, cloud controls, and other components included in the evidence set. Record product families, versions, roles, locations, owners, and collection dates.

The purpose is not to claim that configuration collection replaces every asset-discovery mechanism. It is to make the assessment boundary explicit and expose gaps between the systems the organization believes it has and the configurations it can actually produce.

2. Baseline view: What should be true?

Map relevant settings to vendor guidance, industry benchmarks, regulatory requirements, organizational standards, and documented operating needs.

A baseline should not become a blind checklist. Some deviations are necessary. Some settings have different meanings across products. Some security recommendations conflict with availability, safety, or support constraints. The assessment should preserve those conditions rather than flattening them into a generic pass or fail.

3. Relationship view: What does the environment allow?

Model the connections and dependencies that individual reviews tend to miss:

  • Which routes and rules create paths between trust zones?
  • Which systems can reach administrative interfaces?
  • Which authentication, logging, time, DNS, and update services are trusted?
  • Where do vendor access paths enter?
  • Are segmentation controls consistent across every device that implements the boundary?
  • Do cloud, wireless, remote-access, and legacy paths preserve the same assumptions?

This is where configuration data becomes architecture evidence.

4. Exception view: Why is the deviation present?

Every material deviation should have an owner, business reason, affected scope, compensating control, approval, and review or expiration date.

Without that context, the assessor cannot distinguish a consciously accepted operating requirement from drift, error, or forgotten emergency access. A technically accurate report can still produce poor decisions if it treats every difference as equivalent.

5. Trend view: Is the control getting stronger?

Retain enough continuity to compare assessments over time.

Leaders should be able to see whether high-risk deviations are being removed, whether the same root causes recur, whether one product family or business unit is falling behind, and whether remediation is producing greater control consistency.

A point-in-time result answers, “What did we find?”

A trend answers, “Are we learning?”

Look for Patterns, Not Just Findings

The value of environment-wide analysis is not that it generates more findings.

It is that it can reveal which findings share a cause.

Twenty devices using an obsolete protocol may not represent twenty independent failures. They may point to one outdated standard, one unsupported management tool, one inherited template, or one team that never received the replacement process.

Inconsistent logging destinations may reveal that an acquisition was never integrated into the monitoring model. Repeated access-control exceptions may show that an application architecture depends on flows the segmentation design did not anticipate. Different authentication sources may indicate that administrative identity has fragmented across regions or product generations.

This changes remediation.

Instead of distributing a long list of device-specific corrections, the organization can address the common mechanism: update the standard, replace the template, redesign the path, migrate the dependency, retire the exception process, or assign ownership for the control.

The result is not merely cleaner configurations. It is a more governable system.

Passive Analysis Matters When Touching the Environment Adds Risk

Active discovery and validation remain important. They can reveal live services, reachable paths, unmanaged assets, and runtime behavior that stored configurations do not show.

They are not always the safest first step.

Operational technology, critical infrastructure, legacy equipment, and fragile high-availability systems may impose strong constraints on scanning, agents, appliances, change windows, and test traffic. NIST’s Guide to Operational Technology Security emphasizes that OT security measures must account for performance, reliability, and safety requirements.

Offline analysis of existing configuration evidence can reduce the need to introduce new software or traffic merely to begin understanding the environment. It can help teams identify likely problems, missing evidence, and validation priorities before selecting the safest live tests.

That does not make offline analysis omniscient.

A configuration may be stale. A device may not be represented. Runtime state may differ from the saved file. A rule may exist but never be exercised. An undocumented path may not appear in the collected data. Configuration evidence should therefore guide targeted validation, not eliminate it.

The safer model is complementary:

  1. Analyze the configuration evidence.
  2. Identify systemic risks and uncertain relationships.
  3. Prioritize the live checks that would resolve the most consequential uncertainty.
  4. Reconcile the observed state with the model.
  5. Preserve the updated evidence for the next review.

Where MachineTruth Fits

MachineTruth™ is MicroSolved’s Analytics as a Service platform for offline, passive device and network analysis.

The service can analyze configuration files and supporting network data to help inventory and map environments, compare settings with standards and best practices, examine routing and trust relationships, support segmentation analysis, identify hardening opportunities, and produce documentation for technical and assurance audiences.

Its most important contribution is scale with context.

MachineTruth allows the assessment to look across products, vendors, versions, locations, and business units while MicroSolved analysts validate findings, account for operating constraints, and translate patterns into prioritized mitigation guidance. Multi-year work can preserve organizational standards, accepted risks, reporting preferences, and trends so that later reviews begin with accumulated knowledge rather than a blank checklist.

MachineTruth does not replace asset discovery, live validation, change control, vulnerability management, architecture ownership, or engineering judgment.

It gives those activities a stronger evidence base by answering a question they often struggle to answer:

What security state do the collected configurations create when we analyze the environment as a whole?

Measure Configuration Assurance, Not Review Volume

Counting reviewed devices is useful for scope management. It is not enough to show that the control is improving.

More useful measures include:

  • Percentage of in-scope systems with a current configuration represented in the evidence set.
  • Percentage of critical controls mapped to both an approved baseline and implementation evidence.
  • Number of material cross-device inconsistencies by control domain.
  • Percentage of deviations with an owner, rationale, compensating control, and review date.
  • Age of high-risk configuration drift.
  • Recurrence rate for findings tied to the same template, standard, or process.
  • Percentage of high-consequence network zones whose segmentation is supported by current configuration evidence and targeted validation.
  • Time required to explain an allowed path from source to destination across the relevant controls.
  • Improvement in control consistency between assessment cycles.

One metric is especially revealing:

How long does it take to prove that the network currently enforces the boundary shown on the diagram?

If the answer requires several teams, multiple consoles, undocumented assumptions, and the memory of one experienced engineer, the organization has architecture knowledge but weak architecture evidence.

What Security Leaders Should Do This Week

Choose one high-consequence network zone, service, or business process.

  1. Name the intended boundary. Identify what the zone protects, which communications should be allowed, which should be denied, and which teams own the decision.
  2. Collect current evidence. Obtain the relevant firewall, router, switch, VPN, wireless, cloud, DNS, authentication, and logging configurations using an approved secure process.
  3. Declare the assessment boundary. Record what is present, what is missing, how current the data is, and which runtime questions configuration evidence cannot answer.
  4. Compare across the environment. Look for inconsistent management access, authentication sources, logging destinations, insecure services, unsupported versions, stale rules, and alternate routes.
  5. Test the relationships. Confirm that the combined configurations enforce the intended segmentation and trust model.
  6. Explain every exception. Require an owner, business reason, compensating control, and expiration or review date.
  7. Fix the common causes first. Prioritize templates, standards, tools, and processes that can remove the same weakness from many systems.
  8. Preserve the baseline. Retain the result so the next review can measure drift and improvement rather than starting over.

A network diagram is an important expression of intent.

A device checklist is an important test of local configuration.

Neither, by itself, proves the effective security state of the environment.

The network is created by the way configurations interact.

Review it that way.

Put MachineTruth to Work on Your Environment

MicroSolved, Inc. can help organizations use MachineTruth Global Configuration Assessments to:

  • Analyze device and application configurations at enterprise scale.
  • Reconcile network documentation with collected configuration evidence.
  • Identify systemic hardening, authentication, logging, routing, and access-control issues.
  • Evaluate segmentation and trusted relationships across mixed-vendor environments.
  • Prioritize root-cause remediation instead of distributing disconnected findings.
  • Preserve accepted risks, organizational standards, and improvement trends across assessment cycles.
  • Plan targeted validation for critical, sensitive, and operational technology environments.

To discuss a MachineTruth assessment, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

 

Prompt Injection Should Change What Your AI Agent Is Allowed to Do

Posted on by
Reply

The support agent is authenticated.

Its token is valid. Its access to the ticketing system is approved. Its connection to the customer database is working exactly as designed.

Then it reads a support ticket containing a hidden instruction to retrieve account data and send it somewhere else.

Nothing about the agent’s identity has changed.

Everything about the safety of its next action has.

That is the authorization problem emerging around AI agents. Traditional access control asks whether a known identity may use a resource. Agentic systems add another question: what information is influencing the agent at this moment, and should that information reduce what the agent is allowed to do?

Static permission is not enough for dynamic context.

The National Institute of Standards and Technology put fresh attention on this issue in a September 29 update about its Software and Agentic AI Identity and Authorization project. NIST’s summary of more than 600 public comments says respondents repeatedly called for separate governance or gateway components to evaluate agent requests. Commenters also argued that authorization policy may need to change when prompt injection is suspected—or whenever an agent is working with untrusted data. (NIST NCCoE, September 29, 2026)

That summary is not a final NIST control standard. It is evidence of where the architecture conversation is moving.

The practical lesson is already useful:

When the trustworthiness of an agent’s context decreases, its authority should decrease with it.

CaneCorsoAI

Strong Identity Does Not Make the Context Trustworthy

Identity and authorization remain essential.

Every consequential agent should have a distinct identity. Its credentials should be protected. Tool access should be scoped. High-impact actions should require stronger controls. Tokens should be short-lived where practical. Human sponsorship and delegation should be attributable.

Those controls answer important questions:

  • Which agent is making the request?
  • Which person or organization authorized it?
  • Which tools and data may it use?
  • What limits apply to its role?

They do not necessarily answer:

  • Did the agent just ingest hostile instructions from an email, document, web page, RAG source, or tool response?
  • Did sensitive information enter the prompt context unnecessarily?
  • Did an external source attempt to redefine the agent’s goal?
  • Is the requested action consistent with the original user’s intent?
  • Should the agent still have write, send, execute, or disclose authority after the context changes?

An agent can be the correct identity, using a valid credential, while acting on corrupted influence.

This is why prompt injection is not merely a content-filtering problem. It is a runtime authorization signal.

The recent NIST comment summary describes the same architectural tension. It notes that language-model systems may not reliably separate untrusted data from trusted instruction, and that respondents favored logically separate governance components at multiple points—from user input and prompt processing to tool calls and cross-boundary requests. (NIST NCCoE summary of comments)

The reasoning system should not be the only system deciding whether its reasoning is safe enough to execute.

Use Trust-Responsive Authorization

The goal is not to reinvent identity management.

It is to make authorization responsive to the current trust state of the workflow.

Call this trust-responsive authorization:

Agent authority is determined by identity, intended task, requested action, data sensitivity, source trust, and observed content risk—not by identity alone.

That model allows an agent’s permissions to step down as risk rises.

State 1: Normal

The agent is operating within its approved mission. Inputs come from expected sources, inspection finds no material risk, requested actions remain within policy, and the agent uses only the minimum tools required.

Normal does not mean unlimited. It means the bounded workflow may continue without extra intervention.

Examples might include:

  • Summarizing a known internal knowledge article.
  • Classifying a routine support request.
  • Retrieving non-sensitive status information.
  • Drafting a response without sending it.

State 2: Constrained

The agent encounters untrusted or privacy-sensitive content, but the workflow can remain useful after controls reduce the risk.

The system may:

  • Sanitize or remove suspicious instructions.
  • Tokenize or redact sensitive values.
  • Defang links.
  • Remove write-capable tools.
  • Restrict retrieval to an approved data set.
  • Convert an autonomous action into a recommendation.
  • Prevent external communication or network egress.

The objective is graceful degradation. The organization keeps useful work moving while reducing the blast radius.

State 3: Review

The context contains suspected prompt injection, conflicting instructions, unusual data access, an unexpected tool request, or another condition that makes autonomous action inappropriate.

The agent may continue gathering non-sensitive evidence, but the consequential action pauses for human review.

The reviewer should see:

  • The original business request.
  • The source and trust level of the suspect content.
  • What was detected or changed.
  • What the agent attempted to do.
  • Which data and tools were involved.
  • Which policy required review.

A generic “AI needs approval” message is not enough. The human needs the context required to make a real decision.

State 4: Stop

The request is clearly malicious, violates policy, attempts to expose protected data, seeks an unauthorized action, or cannot be made safe without destroying the purpose of the workflow.

The system blocks or quarantines the transaction. Depending on the situation, it may also revoke a session, disable a workflow, preserve evidence, or trigger incident response.

These states should be defined by system owners before an agent encounters the problem.

An AI agent should not decide for itself when it deserves more authority.

Put an Independent Control Point in the Path

Trust-responsive authorization requires a signal about the content influencing the agent.

That signal should come from a control point that is separate from the model’s reasoning and placed directly in the workflow.

This is the role of an AI Application Firewall.

CaneCorso™ is MicroSolved’s shared control plane for AI workflows. It sits between workflow content and the model or downstream logic. Based on configured policy, it can allow, sanitize, tokenize, or block content; apply privacy controls; and preserve reasons, scores, and evidence for review.

That makes CaneCorso useful as the inspection and enforcement layer in a trust-responsive architecture.

It does not replace identity and access management. It does not replace scoped tool permissions, secure credentials, application authorization, human approval, or incident response.

It gives those systems information they normally do not have:

Is the content influencing this action safe enough for the workflow to continue in its current mode?

A practical integration can work like this:

  1. Inspect the inbound content. Email, documents, tickets, RAG results, API responses, or tool output pass through CaneCorso before entering the model context.
  2. Apply the content decision. Approved content proceeds. Sensitive or suspicious portions can be sanitized, tokenized, defanged, or blocked according to policy.
  3. Map risk to agent mode. The workflow orchestrator uses the disposition to keep the agent in normal mode, remove higher-risk capabilities, require human review, or stop processing.
  4. Limit tool execution. The authorization layer checks the agent identity, requested action, current mode, data sensitivity, and approval state before a tool runs.
  5. Inspect consequential output. Where model output will drive decisions or actions, route it through a second inspection point before downstream execution.
  6. Preserve the decision record. Send the content-risk result, agent identity, tool request, policy decision, approval, and outcome to the organization’s monitoring and audit systems.

MicroSolved’s earlier production-use article describes this two-layer pattern—inspection before model processing and another check before selected downstream use—in Brent Huston’s own agent environment. (Why My AI Agents Needed CaneCorso as a Security Control Plane)

The key design choice is not merely to log the risk score. It is to make the workflow consume the decision.

A Warning Without an Authority Change Is Only Telemetry

Many AI security designs stop at detection.

The system identifies suspicious content. It writes an event. It may notify a security team. The agent continues with the same tools and privileges it had before the warning.

That is visibility, not control.

If a possible injection does not alter the available action set, the organization is asking a later human process to contain a machine-speed decision. The alert may arrive after the email was sent, the record was modified, the file was retrieved, or the tool call completed.

This does not mean every suspicious string should shut down the workflow. Overblocking can make AI systems unusable and encourage teams to bypass the control.

The better design is proportional response:

  • Low-risk privacy exposure can be tokenized while the workflow continues.
  • A suspicious URL can be defanged before analysis.
  • Untrusted text can be summarized with all action-capable tools removed.
  • A suspected injection can force the agent into read-only mode.
  • A consequential request can require human approval.
  • Clearly malicious content can be blocked and preserved for investigation.

CaneCorso’s allow, sanitize, tokenize, and block outcomes support that more nuanced response. The surrounding application determines which tools remain available and which approvals are required.

That separation of responsibilities matters. The content control should not silently become the identity provider, and the identity provider should not pretend it understands prompt semantics.

Test Whether the Boundary Actually Holds

No prompt-injection control should be treated as infallible.

NIST’s March analysis of a large agent red-teaming competition reported more than 250,000 attack attempts by over 400 participants across 13 frontier models. At least one successful hijacking attack was found against every target model. NIST’s takeaway was not that agent use is impossible. It was that evaluations must evolve with adversaries and that comparative red teaming provides information ordinary static tests may miss. (NIST CAISI, March 23, 2026)

The joint Careful Adoption of Agentic AI Services guidance from agencies including CISA, NSA, and the national cyber centers of Australia, Canada, New Zealand, and the United Kingdom recommends input validation and sanitization, prompt-injection filters, continuous evaluation, fail-safe defaults, human control points, runtime monitoring, and regular attempts to bypass safeguards. (Joint guidance, May 1, 2026)

For one representative agent workflow, test the complete control chain:

  1. Establish a normal task and record the intended agent identity, data sources, tools, and allowed actions.
  2. Introduce hostile instructions through realistic sources such as a ticket, email, document, RAG entry, API response, or tool result.
  3. Confirm that CaneCorso identifies, sanitizes, tokenizes, or blocks the content according to the workflow policy.
  4. Confirm that the resulting disposition changes the agent’s available authority as designed.
  5. Attempt a high-impact action after the risk signal and verify that the authorization layer blocks it or requires human approval.
  6. Verify that the agent cannot recover removed capability by rewriting the request, changing language, splitting the instruction across sources, or calling a different tool.
  7. Inspect the record. Confirm that responders can identify the source, agent, content decision, policy state, requested tool, approval, and final outcome.
  8. Test the failure mode. Decide what happens if the control plane, identity service, logging path, or human approval channel is unavailable.

CaneCorso’s Injection Scanner is designed to help exercise these controls before deployment, after changes, and during assurance reviews. The test still needs to cover the full application behavior. Detecting the input is only one link; the system must also constrain the agent and prevent the unsafe action.

Measure the Decision, Not Just the Detection

Counting detected prompts can be misleading.

A high count may indicate active attacks, a noisy policy, a research feed that contains legitimate attack examples, or ordinary content that resembles instructions. A low count may indicate clean inputs—or weak coverage.

More useful measures connect detection to outcome:

  • Percentage of agent actions carrying a recorded content-risk disposition.
  • Time from suspicious input detection to reduced agent authority.
  • Percentage of high-impact actions attempted after a risk signal and correctly blocked or escalated.
  • Percentage of sensitive values tokenized or redacted before model exposure.
  • Rate of safe workflows disrupted by false positives.
  • Rate of risky workflows allowed because a control failed open, timed out, or was bypassed.
  • Percentage of human reviews with enough evidence to explain the requested action and policy decision.
  • Results of adversarial validation before and after model, prompt, tool, policy, or data-source changes.
  • Time required to reconstruct which content influenced a consequential agent action.

The important metric is not “How many injections did we detect?”

It is:

When the context became less trustworthy, did the system reduce authority before harm occurred?

What Security Leaders Should Do This Week

Choose one agent that consumes external or mixed-trust content.

  1. Name the consequential actions. Identify every send, write, execute, disclose, purchase, delete, or privilege-changing capability available to the agent.
  2. Map the influence paths. Include users, email, documents, RAG sources, web content, API responses, tool output, memory, and other agents.
  3. Add an independent inspection point. Put CaneCorso or an equivalent AI Application Firewall before untrusted content reaches the model and before consequential output reaches downstream logic.
  4. Define the four states. Document what Normal, Constrained, Review, and Stop mean for this workflow.
  5. Bind state to capability. Make the orchestrator and authorization layer remove tools, require approval, or block execution as risk increases.
  6. Run an adversarial test. Use realistic indirect prompt injection attempts and verify the action is prevented—not merely detected.
  7. Preserve the reason. Record what influenced the agent, which policy applied, what authority changed, who approved any exception, and what finally happened.

Agent identity answers who is acting.

An AI Application Firewall helps determine whether the content influencing that agent is safe enough to use.

Authorization must connect the two.

If an agent can encounter hostile context while retaining its full authority, the architecture is trusting the moment when it should become most skeptical.

Prompt injection should not merely create an alert.

It should change what the agent is allowed to do.

Put CaneCorso in Front of Your AI Workflows

CaneCorso™ gives organizations a shared AI Application Firewall for email, document AI, RAG, support workflows, copilots, and agent-driven automation.

MicroSolved, Inc. can help you:

  • Map the content, privacy, tool, and authorization boundaries in an AI workflow.
  • Pilot CaneCorso against a representative production use case.
  • Configure allow, sanitize, tokenize, and block policies.
  • Test prompt-injection defenses with CaneCorso’s Injection Scanner.
  • Connect runtime decisions and evidence to monitoring, review, and audit processes.
  • Design constrained, human-review, and fail-safe operating states for AI agents.

To discuss a CaneCorso pilot or schedule a practical review, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

 

A Secure Pipeline Is Not the Same as a Trustworthy Release

Posted on by
Reply

The deployment dashboard is green.

The build completed. The scanners ran. The change ticket is closed. The application is in production.

Now ask a harder question:

Can the organization prove that the software running in production came from the reviewed source, was built in the approved environment, passed the required controls, retained every accepted exception, and arrived without substitution?

If the answer is only, “The pipeline succeeded,” the organization has not answered the question.

A pipeline is a workflow. A trustworthy release is a security claim supported by evidence.

That distinction matters because modern delivery systems do more than compile code. They pull dependencies, execute third-party actions, create infrastructure, retrieve secrets, generate artifacts, promote packages, and deploy to production. A green status can show that automation reached its final step. It does not automatically prove that every important input was authorized, every control ran as intended, or the exact artifact that passed review is the artifact now operating.

The National Institute of Standards and Technology reinforced this point in a September 24 update to its live Secure Software Development, Security, and Operations Practices project. The new material maps the Secure Software Development Framework to a DevSecOps model and adds functional scenarios across the software lifecycle. Those scenarios connect build isolation, integrity checks, provenance, software bills of materials, test records, signing, release policy, and deployment verification.

The practical lesson is straightforward:

Do not trust a release because the pipeline is busy with security tools. Trust it when the evidence remains connected from approved input to verified production artifact.

Green Is a Workflow State, Not a Trust Decision

Security teams commonly describe a pipeline by listing its tools.

There is source-code analysis. There is dependency scanning. There is infrastructure-as-code scanning. There is secret detection. There may be container scanning, dynamic testing, artifact signing, and a software bill of materials.

Each capability can reduce risk. Together, however, they still may not answer basic release questions:

  • Which source commit was actually built?
  • Which dependencies and build instructions were used?
  • Which identity requested and executed the build?
  • Did every required control run, or was one skipped, disabled, or misconfigured?
  • Were findings resolved, suppressed, or accepted as risk?
  • Which immutable artifact was approved?
  • Was that exact artifact deployed?
  • Can the evidence be reconstructed after the pipeline logs expire?

A scanner can report on the artifact it received without proving that the artifact was the one later deployed. A signature can protect integrity without proving that the signer was authorized to approve the release. An SBOM can describe components without proving that the build environment was trustworthy. A ticket can record approval without being bound to a specific artifact digest.

These are not arguments against scanners, signatures, SBOMs, or change records. They are reasons to connect them.

NIST Special Publication 800-204D describes CI/CD pipelines as the flow that takes software through build, test, package, and deployment activities, and it outlines strategies for integrating software-supply-chain security into that flow. The security objective is therefore not merely to add controls at individual stages. It is to maintain confidence as software and evidence move between them. (NIST SP 800-204D)

That requires a release evidence chain.

Build the Release Evidence Chain

A useful release evidence chain answers four questions in sequence:

  1. What entered the build?
  2. What happened during the build and test process?
  3. What exactly was approved for release?
  4. What exactly reached production?

The value comes from continuity. If any link refers to a different commit, run, artifact, environment, or approval, the chain is incomplete.

1. Establish the Inputs

Start with the inputs that define the release.

At minimum, the evidence should identify:

  • The source repository and exact commit.
  • The approved change, review, or pull request.
  • The build definition and versioned pipeline configuration.
  • Direct dependencies and other retrieved build materials.
  • Infrastructure-as-code and deployment configuration.
  • The builder identity and requesting identity.
  • The target environment and release criteria.

This is where apparently reproducible work often becomes ambiguous. A pipeline may reference a mutable branch, a floating container tag, an unpinned third-party action, or a package version range. The build can succeed twice while consuming different material.

The Supply-chain Levels for Software Artifacts provenance specification defines provenance as verifiable information about where, when, and how an artifact was produced. Its model includes the build process, top-level inputs, resolved dependencies, builder identity, and output artifacts. Not every organization needs to implement the highest SLSA level immediately. Every organization should be able to identify the inputs that materially determine a production artifact.

The governing question is:

Can we reconstruct what the build trusted, not merely where the source repository lives?

2. Prove What Executed

The next link is the execution record.

NIST’s functional DevSecOps scenarios describe automated builds using ephemeral environments, integrated analysis, repeatable processes, and logged results. They also demonstrate integrity checks for source, commits, images, binaries, and libraries; provenance creation; signed SBOM generation; and captured scanning output. These are examples rather than universal prescriptions, but they show what trustworthy execution must make visible. (NIST functional demonstration scenarios)

For a consequential release, evidence should show:

  • The build ran in an approved and appropriately isolated environment.
  • The expected pipeline definition executed.
  • Required tests and security checks ran against the intended input or artifact.
  • Results were recorded, including tool errors and incomplete scans.
  • Policy gates evaluated those results.
  • Any manual intervention or override was attributable.
  • The build environment did not quietly modify the release after testing.

This last point is easy to miss. If a package is rebuilt during promotion, if configuration is injected outside the governed process, or if a production image is assembled from components different from those tested, the organization has created a new artifact. Prior evidence may no longer describe it.

The proof should also distinguish passed from did not run. An unavailable scanner, an empty report, a timed-out test, and a successful control are different states. A secure release process fails closed where risk demands it and makes degraded controls explicit where business continuity requires an exception.

3. Bind Approval to the Artifact

Release approval should name the thing being approved.

That normally means an immutable identifier such as a cryptographic digest, accompanied by evidence that explains why the artifact is eligible for promotion. The release packet can be assembled automatically and may include:

  • Artifact name, version, and digest.
  • Build provenance or attestation.
  • Signature and signing identity.
  • SBOM and dependency analysis.
  • Test and scan results.
  • Security and functional acceptance criteria.
  • Open findings and their disposition.
  • Approved exceptions, owners, expiration dates, and compensating controls.
  • Change and release approvals.

NIST’s new functional scenarios explicitly connect release documentation with records from tests, scans, and compliance checks. They also include signing and verification before deployment and policies intended to allow only signed, validated software from approved build and test processes to proceed. (NIST functional demonstration scenarios)

This is more than audit packaging.

If an approver accepts risk for artifact A, the approval should not be reusable for artifact B. If a critical scanner did not run, the record should not look identical to a fully tested release. If an emergency change bypasses a normal gate, the deviation should remain attached to the artifact until it is resolved or retired.

An exception hidden in a ticketing system is not part of the release decision unless the promotion process can find and enforce it.

4. Verify Promotion and Deployment

The final link is often the weakest.

Teams may secure the build, sign the artifact, and preserve provenance—then deploy by a path that does not verify any of it.

Provenance is useful only when a consumer checks it. The SLSA artifact-verification guidance calls for comparing the artifact with its provenance, validating the provenance signature, checking the builder identity, and confirming that build parameters match expectations.

At promotion and deployment, the organization should verify:

  • The artifact digest matches the approved release record.
  • The signature and attestation are authentic and valid.
  • The builder and signer are trusted for that application and environment.
  • Required evidence exists and satisfies policy.
  • The target environment received the approved immutable artifact.
  • Unauthorized or unsigned substitutions are rejected.
  • Deployment and runtime inventory can identify the artifact actually operating.

NIST’s scenarios carry this principle into deployment by verifying SBOM and provenance data before deployment and applying policies so only signed and validated software is deployed. The objective is not to sign everything and declare victory. It is to make authenticity and policy verification part of the consuming action.

This closes the most important gap:

The artifact that passed the controls must be the artifact that received the approval, and the artifact that received the approval must be the artifact that reached production.

An Evidence Packet Is Not a Folder Full of Reports

Organizations sometimes respond to assurance demands by saving more output.

That creates volume, not necessarily proof.

A release evidence packet should be machine-associated with a specific build and artifact. It should preserve relationships, not just documents:

  • Commit to build invocation.
  • Build invocation to artifact digest.
  • Artifact digest to test and scan results.
  • Findings to disposition and exception.
  • Approval to artifact digest.
  • Artifact digest to deployment event.
  • Deployment event to running workload or asset inventory.

The packet does not need to be a single file or a new platform. It can be a set of signed attestations, repository records, policy decisions, tickets, and deployment events. What matters is that the organization can follow the links without relying on memory, screenshots, or an engineer who remembers what happened.

The NIST Secure Software Development Framework is deliberately high-level so organizations can integrate its practices into different development lifecycles. That flexibility is useful. It also means leaders should define what evidence demonstrates each practice in their environment.

“We use the tool” is a capability statement.

“Here is the result for the exact artifact in production, and here is how policy consumed it” is an assurance statement.

Measure Evidence Continuity, Not Security-Tool Count

Counting pipeline tools rewards installation. Counting findings rewards detection volume. Neither measure shows whether the release decision can be trusted.

More useful measures include:

  • Percentage of production releases with verified provenance.
  • Percentage of deployments performed by immutable digest rather than mutable tag or name.
  • Percentage of production artifacts whose signature and approval were verified at deployment.
  • Percentage of required controls that produced a conclusive result for each release.
  • Percentage of exceptions linked to an artifact, named owner, compensating control, and expiration date.
  • Time required to identify the source, builder, evidence, approval, and deployment history for a running artifact.
  • Percentage of emergency releases whose evidence gaps were reconciled within the required time.
  • Number of unauthorized, unsigned, or mismatched artifacts rejected during controlled testing.

One particularly revealing metric is time to prove production:

Starting with a running workload, how long does it take to prove what source produced it, how it was built, what controls ran, who accepted the residual risk, and how the artifact was promoted?

If the answer requires several teams, multiple consoles, and manual correlation, the evidence chain is fragile even when every tool is technically present.

Test One Release End to End

Do not begin with an enterprise transformation.

Choose one internet-facing or otherwise consequential service and one recent production release. Ask a developer, platform engineer, security analyst, and service owner to reconstruct the release together.

Start from production and work backward:

  1. Identify the exact running artifact by immutable digest or equivalent identifier.
  2. Find the deployment event and show that it referenced the same identifier.
  3. Find the approval and confirm that it applied to that artifact.
  4. Retrieve the test, scan, and policy results associated with the artifact.
  5. Identify every exception and verify its owner, rationale, compensating control, and expiration.
  6. Retrieve the provenance, signature, SBOM, and build logs.
  7. Trace the build to the exact source commit, build definition, dependencies, builder, and requesting identity.
  8. Confirm that the evidence is retained long enough for incident response, audit, and operational learning.

Then run a negative test in a safe environment.

Try to promote an unsigned artifact. Change the digest after approval. Skip a required control. Use an unapproved builder. Present provenance with an unexpected parameter. Confirm that the release process rejects the change and produces an event responders can use.

The negative test matters because a dashboard can show that the approved path works without proving that an unapproved path is blocked.

The exercise will probably reveal governance issues as well as technical ones. Teams may disagree about who owns the policy, which findings are release-blocking, how emergency changes are reconciled, how long evidence is retained, or whether a vendor-managed deployment exposes enough detail to verify the chain.

Those disagreements are part of the finding.

Scale Assurance by Consequence

Not every internal script needs the same release process as a payment platform, clinical system, or internet-facing identity service.

Use consequence to set the assurance level.

For low-impact software, a minimum evidence packet may include the commit, build identity, artifact digest, required test results, and deployment record. Higher-impact systems may require isolated or hardened builders, signed provenance, verified SBOMs, independent approval, stronger separation of duties, policy enforcement at deployment, and longer evidence retention.

The important point is to make the differences explicit.

A lower-assurance release should be a risk decision, not an accidental byproduct of team maturity. The organization should know which systems lack provenance, which deployment paths accept mutable artifacts, which controls can be bypassed, and who owns the improvement plan.

This also keeps the program practical. The goal is not to create a paperwork tax that slows every change. Evidence should be generated and connected by the delivery process wherever possible. Human attention should focus on policy, exceptions, high-consequence decisions, and failed verification.

Automation moves software quickly. It should move proof with equal discipline.

What Security Leaders Should Do This Week

Start with one production service and one release.

  1. Name the artifact. Record the immutable identifier for what is actually running.
  2. Trace the chain backward. Connect deployment, approval, test results, build record, and reviewed source.
  3. Find the silent states. Identify controls that can time out, fail open, return empty results, or be skipped without a distinct release decision.
  4. Bind exceptions to releases. Require an owner, rationale, compensating control, expiration date, and artifact reference.
  5. Verify at deployment. Confirm that signatures, provenance, builder identity, and required evidence are checked when software is promoted—not merely created earlier.
  6. Run one negative test. Attempt a safe substitution or skipped-control scenario and verify that the process blocks it.
  7. Measure time to prove production. Set a target for reconstructing the complete evidence chain during an incident or audit.

A modern pipeline can run dozens of tools and still produce an untrustworthy release.

The difference is evidence continuity.

When source, build, controls, exceptions, approval, artifact, and deployment remain bound together, the organization can make a defensible claim about what reached production.

Without that chain, green means only that the workflow finished.

More Information and Assistance

MicroSolved, Inc. can help organizations:

  • Assess CI/CD, DevSecOps, and software-supply-chain controls.
  • Map release evidence from source through production deployment.
  • Review build isolation, signing, provenance, SBOM, and artifact-verification practices.
  • Test release gates, exception handling, and unauthorized-artifact rejection.
  • Design practical assurance tiers for high-consequence systems and vendors.
  • Build release, incident-response, and audit evidence playbooks.

Contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

 

The Same Ten Passwords, Twenty Years Later

Posted on by

We’ve been logging the credentials that bots throw at an SSH honeypot (our HoneyPoint Security Server™). Nothing exotic: listeners that accept the handshake, record the username/password pair, and the source IP. After letting this run for a bit, the first thing we noticed was how little the dictionary has changed.

HoneyComb

The numbers

Top usernames over the capture window:

Username Tries Sources
root 45,302 350
admin 3,254 256
user 1,978 132
enable 1,863 12
test 1,414 101
ubuntu 1,142 125
user2 452 26
debian 433 39
deploy 387 47
support 372 104

root alone accounts for more attempts than everything else combined, by a factor of about four. That’s not surprising. What’s worth noticing is the sources column: 350 distinct IPs tried root, 256 tried admin. This is the broad, low-effort campaign layer to find the most basic common hanging fruit.

Continue reading →

Authentication Is Not the Finish Line: Secure the Token Lifecycle

Posted on by
Reply

A user signs in with a passkey. The authentication is phishing-resistant. The identity provider records a successful challenge. Every dashboard says the login worked as designed.

Hours later, an attacker reuses a stolen session token.

No password is entered. No push notification appears. No new authentication ceremony occurs. The application sees a valid artifact and accepts it.

Both facts can be true at the same time: the authentication was strong, and the session was compromised.

That is the identity problem security programs need to address next.

Passkeys, hardware security keys, conditional access, and stronger account recovery are essential. They protect the process of establishing identity. But modern applications rarely ask a person or workload to prove identity again for every action. They rely on tokens and assertions that carry the result of an earlier decision across applications, APIs, clouds, and sessions.

The security boundary therefore does not end at login. It moves with the token.

NIST and CISA made that point operational in the final September 2026 release of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. The report addresses the keys that create trust, the systems that validate it, the lifetime of tokens, session monitoring, revocation, workload identity, and the division of responsibility between cloud providers and their customers.

The practical lesson is straightforward:

Treat every token as a live authorization decision, not as a receipt proving that authentication once succeeded.

An award winning portrait of a beautiful red headed woman bokeh lights in background cinematic lighting realistic very sharp 8k 3d render

Continue reading →

Three Field Guides for the Security Problems Showing Up Right Now

Posted on by
Reply

Over the last several months, we have released three longer-form guides around problems we keep seeing in real environments:

  • The Antifragile SOC Book
  • The AI Agents Management Framework
  • The Security Leader’s Operating System

They cover different areas, but they share a common theme: how to operate effectively as complexity, automation, and pressure increase.

Books

Why We Created These Materials

These guides did not begin as content projects.

They came from working problems.

Over the years, we have accumulated a lot of models, processes, questions, and operating approaches that we use when helping organizations solve difficult security problems. Some came from client work, some from research, and plenty came from lessons learned the hard way.

Much of that knowledge lived in conversations, notes, presentations, and experience.

We decided it was time to write more of it down.

Not as theory, and not as another collection of cybersecurity predictions.

As practical field material people can use, challenge, adapt, and apply.

Continue reading →

The Top Three Things Security Teams Need to Understand About AI-Driven Attacks

Posted on by
Reply

The easiest mistake security teams can make about AI-driven attacks is to imagine a completely new species of adversary.

That is not what most organizations are facing.

The objectives remain familiar: steal credentials, gain access, persist, move laterally, collect data, commit fraud, extort the victim, or conduct espionage. What AI changes is the economics of the attack. It reduces the time, expertise, and attention required to move from one step to the next.

That distinction matters because it tells defenders where to act.

Google Threat Intelligence Group reported this week that it has observed adversaries moving beyond basic prompting into agentic workflows and AI-enabled automation. In one Q2 2026 case, a threat actor used an AI coding chatbot and agent instructions to help plan, build, and execute a mass credential-harvesting campaign in less than six hours. The framework automated scanning, troubleshooting, and IP rotation with limited human involvement. (Google Threat Intelligence Group, September 8, 2026)

That does not mean every attacker has become an autonomous machine. It means the constraints that used to slow attackers down are weakening.

OnlineScammer

Security teams need to understand three things.

Continue reading →

Introducing The Security Leader’s Operating System

Posted on by
Reply

There is one sentence I hear from information security leaders more than almost any other:

“I don’t have time to do what I need to do.”

The problem usually isn’t motivation, discipline, or effort. Security leaders already work hard. The deeper problem is that their ability to handle difficult work attracts more difficult work.

Questions, approvals, exceptions, vendor reviews, audit requests, incidents, meetings, unfinished decisions, and executive concerns all flow toward the person who has demonstrated that they can carry them. Eventually, being able to handle almost anything becomes the reason the leader has time to think about almost nothing.

I wrote The Security Leader’s Operating System to help change that.

Thinking

Security Leaders Don’t Need Another Productivity Trick

Most productivity systems concentrate on organizing work after it has already been accepted.

This field guide starts earlier.

Before deciding where a task belongs, it asks whether that work should exist in its current form at all. It applies the EDSAM mental model:

  • Eliminate work that does not need to happen.
  • Delegate outcomes that do not require the leader’s authority or judgment.
  • Simplify work until it produces the smallest useful result.
  • Automate the predictable parts of the work that remains.
  • Maintain only what must remain under the leader’s direct care.

The objective is not to help security leaders process an endlessly growing queue more quickly. It is to redesign the system so that less work requires the leader in the first place.

Continue reading →