Software Development Security

Decision frame

Software security begins with business and security requirements and continues through architecture, acquisition, design, coding, testing, release, operation, change, and disposal. Finding vulnerabilities late is expensive; designing unsafe authority, data flow, or trust boundaries cannot be repaired by a scanner alone.

Treat source, dependencies, build systems, artifact registries, deployment pipelines, secrets, test data, environments, and suppliers as one software supply chain. Protect both the product and the machinery that produces it.

Objective map

Security throughout the lifecycle

During concept and requirements, identify assets, users, data, obligations, misuse, availability, recovery, and assurance. Write testable security requirements and acceptance criteria. During architecture, model trust boundaries, entry points, identity, authorization, data flows, failure, dependencies, administrative planes, and abuse cases. Select secure patterns and reduce unnecessary attack surface.

During implementation, use supported languages and frameworks, secure coding standards, peer review, automated checks, dependency governance, secret scanning, and isolated development access. During verification, combine unit, integration, abuse, authorization, static, dynamic, composition, fuzz, configuration, and manual tests according to risk. During release, protect artifacts, approvals, deployment identity, configuration, rollback, and post-deploy validation. During operation, monitor, patch, respond, measure, and reassess. At disposal, remove data, credentials, endpoints, artifacts, dependencies, and support obligations safely.

Agile and DevOps do not remove governance; they move it into iterative criteria and automation. Threat models and requirements should evolve with features. DevSecOps integrates security into the delivery flow while preserving independent review and separation for high-risk changes.

Protect the development ecosystem

Require individual identities, strong authentication, least privilege, branch and review protections, signed or attributable commits where appropriate, and controlled administrative access. Separate code approval, artifact publication, and production deployment according to risk. Protect CI runners from untrusted code and prevent pull requests from obtaining production secrets.

Store secrets in approved systems and issue short-lived workload credentials when possible. Do not place credentials in source, build logs, images, artifacts, environment dumps, or test fixtures. Scope pipeline roles to target environment and approved actions. Protect pass role or equivalent delegation paths.

Pin and verify dependencies according to ecosystem; maintain lockfiles, approved registries, provenance, software bills of materials where useful, vulnerability monitoring, license review, and update policy. A clean vulnerability scan does not prove a dependency is trustworthy. Protect build configuration, compiler, package manager, plugins, and base images.

Establish artifact identity and immutability. Promote the same tested artifact rather than rebuilding separately for production. Record source commit, dependencies, build environment, tests, approvals, artifact digest, deployment, and rollback. Separate development, test, staging, and production data and credentials. Use synthetic or minimized test data.

Measure software assurance

Measure coverage of requirements and abuse cases, critical findings, age, recurrence, escaped defects, time to remediate, dependency freshness, exception duration, review effectiveness, and verified closure. Raw finding counts reward noisy tools. Test coverage is useful but does not prove assertions are meaningful or critical paths are covered.

Static analysis can find patterns without execution; dynamic testing observes running behavior; composition analysis inspects components; interactive and runtime techniques add context; manual review finds logic and authorization flaws. Calibrate tools, validate findings, and combine methods. Threat-informed tests should verify expected deny behavior, not only successful paths.

Root-cause analysis should improve standards, frameworks, reusable components, pipeline controls, training, and architecture—not only patch one line. Preserve regression tests for vulnerabilities and incidents.

Acquired software and suppliers

Define security requirements before procurement. Evaluate supplier development practices, provenance, architecture, data use, access, hosting, subcontractors, incident history, vulnerability disclosure, patch timelines, support, resilience, escrow where relevant, export, deletion, and exit. Put material obligations, evidence, notification, remediation, audit, data, and end-of-life terms into contracts.

Validate the product in the organization's configuration and use case. A third-party assessment is point-in-time and scope-limited. Monitor new vulnerabilities, ownership changes, dependencies, support status, and service behavior. Plan replacement and data extraction before lock-in becomes a crisis.

Secure coding decisions

Validate input at a defined trust boundary with allowlists and schema. Encode output for its destination. Use parameterized queries and safe APIs to prevent injection. Enforce authorization on every protected server-side action and object. Protect sessions, tokens, cookies, and state-changing requests. Limit upload type, size, content, storage, and execution. Handle errors without exposing secrets or internals while retaining secure diagnostic evidence.

Use cryptographic libraries and approved protocols rather than custom algorithms. Store passwords with an approved salted adaptive password hashing scheme. Prevent unsafe deserialization and dynamic evaluation. Constrain server-side requests and outbound network access. Protect concurrency and transaction integrity. Use memory-safe languages or strong memory-safety controls where feasible, while recognizing logic flaws remain.

Design abuse resistance: rate limits, quotas, fraud controls, replay protection, idempotency, resource limits, and monitoring. Privacy-by-design minimizes data and gives lifecycle control. Accessibility and usability are security considerations because unusable controls invite bypass.

Decision patterns

Scenario drill

A team must ship a critical service using third-party code, cloud CI/CD, open-source dependencies, and a supplier library with limited assurance evidence.

1. Define security, availability, data, support, vulnerability, and provenance acceptance criteria.
2. Threat-model repository, CI runner, dependencies, artifact, deployment role, runtime, and supplier update path.
3. Isolate untrusted builds and keep production secrets unavailable.
4. Generate an attributable immutable artifact and promote the tested digest through environments.
5. Validate authorization, input, output, secrets, dependency, abuse, recovery, and rollback behavior.
6. Document supplier gaps, compensating controls, owner, expiry, monitoring, and replacement plan.

Common traps

• Adding security testing only after coding is complete.
• Giving pull-request builds production secrets.
• Rebuilding the “same” release separately for production.
• Measuring scanner finding count as software quality.
• Trusting acquired software because the supplier is large or certified.
• Testing authentication but not object-level authorization.
• Fixing one defect without a regression test and root-cause control.

Self-check

1. Map one security requirement through design, code, test, release, and operation.
2. Threat-model the path from contributor to production artifact.
3. Select complementary testing methods for a public API.
4. Write five contract requirements for a critical software supplier.
5. Turn one recurring coding weakness into a systemic prevention and regression strategy.

Primary references

• ISC2 CISSP exam outline
• NIST Secure Software Development Framework
• OWASP Application Security Verification Standard
• OWASP Top 10