Security stopped being an add-on
Not long ago, security in many software projects was a late-stage checklist: build the product, then ask someone to test it. That approach has increasingly given way to treating security as a design constraint present from the first sketch. The reasons are practical. Fixing a flaw after release costs more than preventing it, a single incident can damage customer trust, and a growing body of law and contract terms demands evidence of care.
This article looks at the effects on tech companies: how products are designed, who gets hired, what compliance involves and where the money goes. It does not cover the threats themselves, which are surveyed in the piece on emerging cyber threats.
Effects on product design
Secure defaults. Products are increasingly expected to be safe out of the box: unique credentials instead of a shared factory password, encrypted connections by default, and unnecessary services switched off. The case against default credentials is now so established that regulators in several regions have moved to restrict them for connected products.
Updates as a feature. A device or app that cannot be patched is a liability. Designing a trustworthy update path, with signed packages and a way to recover from a failed update, is now part of the basic engineering work. The reasons are laid out in the discussion of firmware updates, and hardware features such as secure boot exist to make sure only trusted code runs.
Data minimisation. Data that is never collected cannot be leaked. Product teams are asked what they truly need to store, how long, and who can see it. This affects analytics, logging and features that depend on personal information. Encryption for stored and transmitted data, as described in data encryption, is a baseline rather than a bonus.
Threat modelling. Teams ask “what could go wrong, and who might make it go wrong?” while a feature is still on paper. The point is to find design flaws that testing alone would miss.
Trade-offs with usability. Stronger sign-in, extra confirmations and tighter permissions all add friction. Good product design looks for ways to improve safety without driving people to work around it, which is one reason passwordless sign-in and password managers have attracted attention.
Constraints on small devices. Embedded products face limits on memory, power and cost, so security features must fit. Makers building connected projects face a scaled-down version of the same issues, covered in a maker guide to connected project security.
Effects on development practice
Engineering teams have adapted the way they work. Common elements include:
- Code review and automated checks. Security-focused review and scanning tools run alongside automated testing.
- Pipeline integration. Security checks are built into CI pipelines so problems are caught before release.
- Dependency management. Modern software leans on many third-party libraries, so teams track what they use and watch for known vulnerabilities. Some customers now ask for a list of components, often called a software bill of materials.
- Secrets handling. Tokens and passwords are kept out of source code, avoiding the sort of mistake described in API key secrecy.
- Penetration testing and audits. Outside specialists are hired to test products and processes.
- Vulnerability reporting. Many companies publish a way for researchers to report problems, and some pay rewards. Handling reports well is the practical side of responsible disclosure.
- Open source involvement. Because so much commercial software rests on shared libraries, companies increasingly support and audit open source contributions to the projects they depend on.
Effects on hiring and organisation
Security work has grown into a range of roles: application security engineers, people who respond to incidents, analysts who watch for suspicious activity, specialists in cloud configuration, governance and risk staff, and testers. Many industry commentators report that employers find it hard to fill some of these roles, although the exact scale of any shortage is debated and varies by region and seniority.
Inside companies, the trend is to spread responsibility. Rather than a single security team that says no at the end, organisations try to embed security-aware people in product teams and train all developers in the basics. Smaller companies often rely on outside providers and managed services because they cannot afford a full in-house team.
Compliance and regulation
Compliance is a major driver of security spending. Without going into detail on any one law, the main kinds of obligation are:
- Data protection laws that govern personal information and often require breach notification.
- Industry rules for sectors such as payments, health and finance.
- Voluntary frameworks and certifications, such as widely used information security standards, that customers ask suppliers to hold.
- Contract terms in which large customers require audits, questionnaires and specific controls from vendors.
- Product security rules that increasingly apply to connected devices.
Compliance and security are related but not identical. Passing an audit shows that certain processes exist at a point in time; it does not guarantee that a system is safe. Mature teams treat compliance as a floor and not a finish line.
Because laws differ by country and change, businesses should seek qualified legal advice rather than assume a general summary applies to them.
Costs and economics
Security costs money in several ways: tooling, staff, audits, insurance, slower releases and the engineering time spent on updates and fixes. Against this stand the costs of incidents: investigation, recovery, legal fees, lost business and reputational harm. Because those losses are uncertain and rarely appear in the budget until they happen, security can be hard to justify, which is why compliance requirements and customer demands often drive decisions.
Several effects follow:
- Larger companies can spread fixed security costs and may find it easier to meet requirements; small startups often lean on shared services and cloud platforms with security features built in.
- Security can be a selling point, especially for products handling sensitive data.
- Insurance providers increasingly ask about basic controls such as multi-factor authentication and backups.
- When an AI feature is added to a product, the security and privacy costs of sending data to a provider, as discussed under cloud AI privacy, belong in the decision.
Effects on users and makers
For customers, the trend generally means more secure defaults, more frequent updates and more prompts to improve account protection, such as enabling two-factor authentication. It can also mean features removed, older devices dropped from support, and occasional inconvenience.
For hobbyists and independent developers, the lesson is that good habits scale down. Keep dependencies updated, avoid shipping secrets, document how to report problems and plan for updates from day one.
What to expect
Reasonable expectations, without promising specifics, include continued growth in security obligations for connected products, more attention to software supply chains, more emphasis on proving security practices to customers, and ongoing pressure on companies to disclose incidents. Costs are likely to remain significant, and companies will keep debating how much is enough. The balance between shipping quickly and shipping safely is not a problem that will be solved once; it is a trade-off that every team manages continuously.