Industry Brief: Technology Company Cyber Risk Priorities

Why this sector ranks differently

A technology company is rarely only a victim. It is also a vendor, and its weaknesses become its customers’ incidents. The cloud accounts, build systems, support tools and administrative interfaces that keep the business moving are the same ones that connect it to every customer.

Change is constant: new services, new dependencies, new environments, new engineers. A control assessed at one point in time ages quickly. That changes how to rank. A list of the biggest vulnerabilities misses the pattern, which is that the access path matters more than the individual flaw.

One weakness, four incidents

Four publicly documented incidents, none of them exotic, show the pattern. In each, an ordinary gap in identity, configuration or dependency control gave access that reached well beyond the system where it started.

INCIDENT	WHAT THE SOURCE REPORTS	WHAT IT SAYS ABOUT PRIORITIES
Snowflake customer accounts	Mandiant found attackers used valid credentials stolen by infostealer malware, against accounts without multi-factor authentication and without network allow lists. About 165 organizations were notified as potentially exposed. Mandiant said the activity was not a breach of Snowflake’s own enterprise environment.	Controls that customers must switch on are a vendor’s problem too. Defaults decide outcomes.
Microsoft corporate email	Microsoft reported that the actor password-sprayed a legacy, non-production test account with no multi-factor authentication, then used a legacy test application with elevated access to create malicious applications and reach corporate email.	Non-production and legacy identities can carry production-level reach.
Okta support system	Okta reported that a service account’s credentials were saved in a personal Google profile used on a managed laptop. The attacker reached support files that included HTTP Archive (HAR) files containing session tokens. Files belonging to 134 customers were accessed and five customers’ sessions were hijacked. Okta’s logs did not flag the suspicious downloads for about two weeks, because downloads from the Files tab generate a different log event from opening case attachments.	Support tooling holds customer secrets, and detection depends on the log events someone chose to monitor.
tj-actions/changed-files	CISA reported that a compromised GitHub Action could disclose secrets, including access keys, personal access tokens, npm tokens and private RSA keys. It advised updating, auditing affected workflows and rotating secrets.	Build dependencies run with your secrets. Trusting a dependency is a risk decision.

The priority order

RANK	PRIORITY	WHY IT RANKS HERE	DECISION IT FORCES
1	Identity and privileged access, human and non-human	Each incident above began with an identity or credential	Require phishing-resistant authentication for staff and administrators; give every service account, token and OAuth application an owner and an expiry
2	Cloud production access	The control plane can create, copy and delete everything	Separate production identities from corporate ones; make elevated access time-bound; apply guardrails at organization level
3	Build pipeline and software supply chain	Pipelines hold the secrets and ship the product	Pin and review dependencies; use short-lived pipeline credentials; protect signing keys
4	Intellectual property	Source code, signing keys, models, roadmaps and customer data concentrate value	Name the crown-jewel assets; restrict bulk export; alert on mass access
5	Customer-facing support and administration tooling	These tools hold customer secrets and customer-wide reach	Treat as production: strong authentication, data minimization, retention limits

1. Identity, including the identities nobody counts

Service accounts, API tokens, OAuth applications and pipeline credentials usually outnumber employees, and they are rarely owned, reviewed or expired. The Microsoft and Okta incidents both turned on identities of this kind: a test application with elevated mailbox access in one case, a service account with case-handling rights in the other.

Assign every non-human identity an owner and an expiry. Remove standing privilege where short-lived access will do. Require phishing-resistant authentication for administrators, and find the accounts that bypass multi-factor authentication before an attacker does.

2. Cloud production access

Identity is how the cloud control plane is attacked, so the two are one problem. Separate the identities that administer production from the ones used for email and browsing. Make elevated access time-bound and logged. Apply guardrails at the organization or account-hierarchy level, so a new team cannot create an unprotected environment by default. Keep logs where a compromised production account cannot delete them.

3. Build pipeline and software supply chain

A pipeline is a privileged system that runs other people’s code with your secrets. The tj-actions incident shows how a popular dependency, trusted by many projects, became a route to credentials.

NIST’s Secure Software Development Framework (SP 800-218) sets out practices for reducing vulnerabilities in released software, limiting the damage when one is exploited and addressing root causes. It also gives buyers and producers a shared vocabulary for acquisition conversations. For a technology company that is useful twice: it structures the internal program, and it gives customers’ security reviews something specific to ask about.

Pin dependencies to reviewed versions. Issue short-lived credentials to pipelines in place of stored secrets. Then test the part most teams skip: whether every secret and token can actually be rotated within a day.

4. Intellectual property

Intellectual property in a technology company is a list: source code, signing keys, model weights and training data where relevant, unreleased roadmaps, customer data. Not everything on it deserves the same protection. Name the few assets whose loss would change the company’s position, restrict who can clone or export them in bulk, and alert on unusual volume.

Signing keys deserve separate treatment. Their loss turns the company’s own releases into an attack on its customers.

5. Customer-facing support and administration tooling

Support systems collect what customers send to get help, and what customers send often includes secrets. The Okta incident is the documented example. Minimize what support tools keep, redact where possible, delete on a schedule, log and review staff access, and make sure bulk downloads from these systems raise the same alerts as bulk exports anywhere else.

Velocity and control are not opposites

Engineering teams resist security work because it costs engineering time. The way through is to move control to where engineers already work: default-secure templates for new services and pipelines, policy enforced as code instead of review meetings, short-lived credentials that remove rotation as a chore, and exceptions that expire automatically and appear on a list someone owns.

None of this slows a release that follows the template. It slows only the release that deviates, and that is the one worth slowing.

Your customers inherit your incidents

Mandiant’s recommendations after the Snowflake campaign included enforcing multi-factor authentication and restricting access to trusted locations. Both are customer-side settings. A company that sells a platform can decide whether such protections are optional. Making them the default, and making it a deliberate act to turn them off, moves risk off customers and off your own incident list.

Decide in advance how you will tell customers, what telemetry you give them to detect misuse of their accounts, and who speaks for the company when they ask.

What to rank lower

Perimeter investment beyond what cloud and identity controls already cover.
Remediating every vulnerability in development dependencies without asking whether the code is reachable and what it can touch.
A single annual penetration test as the main assurance while pipeline and identity controls go untested.

Resilience decisions to make before an incident

Can production be rebuilt from code and clean images if a cloud account is compromised?
Can every secret and token be rotated within a day, as an incident like tj-actions requires?
Which environment is the recovery source, and who can alter it?
Who decides to take a service offline, and who tells customers?

Questions for the next leadership review

How many non-human identities do we have, and which have no owner or expiry?
Which administrative accounts still lack phishing-resistant authentication?
Could we rotate every pipeline secret in one day, and have we tested it?
Which assets would change our position if lost, and who can export them in bulk?
Which protections are optional for our customers that should be on by default?

Sources

Google Cloud Threat Intelligence (Mandiant). UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion.
Microsoft. Midnight Blizzard: Guidance for responders on nation-state attack. Microsoft Security Blog.
Okta Security. Unauthorized Access to Okta’s Support Case Management System: Root Cause and Remediation.
CISA. Supply Chain Compromise of Third-Party GitHub Action tj-actions/changed-files. CISA alerts.
NIST. Secure Software Development Framework (SSDF), SP 800-218.