Back to the topic overview

Secure software lifecycle

Secure Development

Secure development means thinking about security throughout the life of the software. It starts with planning and continues through design, coding, release, and operation. A final scan is not enough.

The aim is simple: find problems while they are still easy to change, and keep learning once the software is in use.

Security is a feedback loop, not a finish line

Every release depends on choices. What may the software do? Which data may it handle? Who may take sensitive actions? How will the team spot and fix problems later? Secure development makes these choices visible.

NIST groups the work into four areas: prepare the organization, protect the software and its development environment, produce secure releases, and respond to vulnerabilities. These ideas can fit a small team or a large company. The controls will differ, but the questions are similar.

OWASP SAMM also treats security as ongoing work across governance, design, implementation, verification, and operations. A late test cannot repair a vague requirement. And a good design will not protect a system that nobody monitors or patches.

A better question than 'Did security approve this?' is: 'Which risk are we reducing, what evidence do we have, and who owns the decision?'

A practical secure-development lifecycle

These stages overlap and repeat. A small change may take hours. A high-impact system may need formal reviews. The basic decisions stay the same.

  1. 01 · Plan

    Describe what the feature should do, which data it uses, who will use it, and how it could be abused. Turn the important risks into requirements you can test.

  2. 02 · Design

    Map data flows and trust boundaries. Think through likely failures. Choose safe defaults and limited permissions before the design becomes expensive to change.

  3. 03 · Implement

    Use maintained frameworks and proven controls for identity, access, input, secrets, and encryption. Keep changes small enough to review.

  4. 04 · Review

    Review the requirement, design, code, tests, and configuration together. Tools can flag patterns. A person still has to understand the business rules.

  5. 05 · Verify

    Test the security requirements. Add code analysis, dependency checks, secret scanning, and focused manual tests where they help. Passing a tool is not the goal.

  6. 06 · Build and release

    Protect source code, build systems, credentials, and release files. Know what went into a release and keep a tested rollback path.

  7. 07 · Operate

    Monitor useful security events without logging secrets. Maintain dependencies and give users a way to report problems. Responsibility does not end at release.

  8. 08 · Learn and improve

    Use vulnerabilities and incidents as feedback. Fix the defect, then improve the requirement, test, default, or process that allowed it.

Where explicit decisions matter most

Some decisions need a clear owner. A framework or scanner cannot make them for the team.

Identity and access

Define who may do what and under which conditions. Login proves identity. The application must still check permission for each sensitive action and record.

Inputs and workflows

Validate untrusted data on the server. Test what happens when valid steps are repeated, skipped, or used in a different order.

Secrets and cryptography

Keep credentials out of code and logs. Limit access, support rotation, and use established cryptographic libraries.

Dependencies and builds

Know which components and build steps enter a release. Apply updates in time, test compatibility, and keep a rollback option.

Configuration and deployment

Use safe defaults, separate environments, and restrict production access. Check that deployment automation applies the intended settings.

Logging and response

Decide what to log, who receives alerts, and how long evidence is kept. Prepare a path to contain, patch, and explain a vulnerable release.

Example: adding a customer-data export

A small SaaS team adds a CSV export for customer records. Only current administrators may export data from their own tenant. Each export must be logged, large exports need limits, and temporary files must not remain on the server.

The team maps the browser, API, database, and download path. It considers stolen sessions, changed tenant IDs, spreadsheet formulas, repeated exports, and fields that should never leave the system. The query is limited to the authenticated tenant and only approved columns are exported.

The code uses the application's existing authorization helper and CSV library. Tests cover normal use, non-admin users, another tenant's ID, revoked roles, dangerous cell prefixes, limits, and logging.

After release, the team watches export volume and failures. If a new edge case appears, it fixes the code and adds a regression test.

Common mistakes and real trade-offs

Security work can become a ritual that produces little useful evidence. The team should make trade-offs visible and reviewable.

Treating a scanner as the process

Automated checks find repeatable patterns. They cannot define the trust model, understand ownership, or judge how a workflow can be abused.

Moving everything left

Early feedback is useful. But monitoring, patching, vulnerability reports, and incident learning only happen once a system is running.

Copying a framework wholesale

SSDF, SAMM, and ASVS provide structure, not a universal checklist. Choose controls that match the system and its risks.

Letting severity scores make decisions

A score does not know which data the system holds or how a failure affects customers. Priority needs context and an owner.

Patching without change control

Delaying an update leaves known risk in place. Applying it blindly can break production. Test, roll out in stages, and keep a rollback path.

Assigning security to one specialist

Specialists add depth. But developers, product owners, operators, and leaders each own different security decisions.

Limits, ownership, and proportionality

No framework, toolchain, or certificate proves that software is secure. Evidence applies to a specific version, configuration, environment, and set of assumptions. It gets weaker as the system changes.

The process should match the risk. A small internal tool needs less ceremony than safety-critical software. It still needs clear ownership of access, data, changes, and response.

Automation should make good decisions easier to repeat. People still set requirements, approve exceptions, accept remaining risk, and respond when reality differs from the design.

  • Name an owner for each material security decision
  • Record assumptions and evidence, not only approvals
  • Make exceptions narrow, time-bound, and visible
  • Keep production feedback connected to development
  • Revisit controls when the system or its impact changes

Key takeaways

  • 01Build security into the development method you already use.
  • 02Turn important risks into clear requirements before coding starts.
  • 03Combine design review, tools, focused tests, and production feedback.
  • 04Protect the build path as carefully as the application code.
  • 05Match controls to the risk and record who owns each exception.
  • 06Use vulnerabilities and incidents to improve the next release.

Sources and further reading

A compact selection of primary sources, standards, and public technical guidance used to ground this article.