Secure Systems Acquisition and Development

Introduction

Organizations rarely build or acquire information systems solely for technical reasons. Systems are purchased or developed to support business processes, deliver public services, store sensitive information, and create competitive advantage. Consequently, security must be treated as a business and engineering requirement from the earliest procurement decision through operation, maintenance, and retirement.

A system that is secure only after deployment is usually expensive to repair and may already expose users, data, and the organization to harm. Secure systems acquisition and development therefore integrates confidentiality, integrity, availability, authenticity, privacy, resilience, and accountability into governance, project management, architecture, coding, testing, deployment, and supplier relationships.

This chapter uses the systems development life cycle (SDLC), secure software development practices, DevSecOps, threat modeling, secure coding governance, application security testing, change management, and software supply-chain assurance as connected elements of one management process.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain why security must be integrated into procurement and the SDLC.
2. Compare traditional SDLC approaches with DevSecOps.
3. Apply threat modeling to identify and prioritize system risks.
4. Describe governance controls for secure coding and application testing.
5. Evaluate software suppliers, dependencies, and supply-chain risks.
6. Design security-aware change-management and acceptance processes.
7. Analyze the organizational, ethical, legal, and managerial consequences of insecure acquisition and development.

1. Security as a Lifecycle Responsibility

Security is a property of a system’s people, processes, technology, and operating environment. It cannot be added reliably through a final penetration test. Security requirements should be established when the business need is defined, refined during architecture and design, verified during implementation, and monitored after release.

A useful lifecycle view includes:

• Planning and initiation: identify business objectives, stakeholders, information types, legal obligations, and risk tolerance.
• Requirements analysis: define functional, security, privacy, resilience, and assurance requirements.
• Design: select architecture, trust boundaries, identity controls, cryptographic protections, logging, and recovery mechanisms.
• Implementation: apply secure coding standards, peer review, dependency management, and developer training.
• Verification and validation: test whether the system satisfies requirements and withstands realistic misuse and attack.
• Deployment: approve release, configure securely, document operational procedures, and prepare monitoring.
• Operations and maintenance: patch, monitor, manage vulnerabilities, control changes, and reassess threats.
• Retirement: preserve or dispose of data appropriately, revoke access, and securely decommission components.

Security requirements should be measurable. “The application must be secure” is not testable. A stronger requirement might state that privileged access must use multifactor authentication, administrative actions must be logged with synchronized timestamps, and audit records must be protected from unauthorized alteration.

Security Objectives and Risk

Risk is commonly analyzed as the relationship between a harmful event, its likelihood, and its consequence. A simple qualitative model is:

Likelihood represents the estimated chance of an adverse event under stated assumptions; impact represents the resulting harm to confidentiality, integrity, availability, safety, finances, compliance, or reputation. This expression is a prioritization aid, not a universal probability equation. If likelihood is expressed as a probability and impact as a monetary loss, the expected loss is:

Here, P(Event) is a probability between 0 and 1 and Loss(Event) is measured in a defined unit, such as currency. The calculation assumes that the event definition is clear and that the estimated probability and loss are meaningful. Real security decisions also include uncertainty, dependencies among events, and nonfinancial consequences.

2. Procurement and Security Requirements

Acquisition decisions create long-term security consequences. A low purchase price may conceal high costs for customization, integration, incident response, unavailable patches, or regulatory remediation. Procurement teams should therefore evaluate security as part of value, not as an optional technical feature.

Security in the Procurement Process

A security-aware procurement process normally includes:

1. Information classification: determine what data the product will handle, including personal, financial, health, confidential, or regulated information.
2. Risk and impact assessment: identify plausible threats, business dependencies, recovery needs, and consequences of supplier failure.
3. Security requirements: specify authentication, authorization, encryption, logging, vulnerability management, privacy, availability, secure development, and incident notification requirements.
4. Supplier due diligence: examine the supplier’s security governance, development practices, assurance reports, vulnerability history, personnel controls, subcontractors, and financial stability.
5. Evaluation and evidence: require demonstrations, independent assessment reports, test summaries, architecture descriptions, certifications where relevant, and references.
6. Contractual controls: define responsibilities, audit rights, notification periods, data location, breach cooperation, patch commitments, support duration, exit rights, and deletion or return of data.
7. Acceptance and transition: verify that delivered controls operate as specified before production use.

A certification can provide useful evidence, but it is not proof that a product is secure in every implementation. Organizations must assess scope, date, assumptions, exceptions, and whether the assessed service is the one being purchased.

Security Requirements in Contracts

Important clauses may address:

Requirements should distinguish between security objectives, controls, and evidence. For example, the objective may be protection against unauthorized administrative access; controls may include privileged access management and multifactor authentication; evidence may include configuration records, test results, and access logs.

3. SDLC Models and Secure Development

Traditional sequential models can provide formal documentation and approval gates, but security feedback may arrive late. Agile methods provide frequent delivery and customer feedback, yet security can be neglected if it is not represented in the backlog, definition of done, and planning routines.

A secure SDLC does not require one particular methodology. It requires security activities to be integrated into whichever methodology is used.

Security Activities by Lifecycle Stage

Security should be represented in project governance. A project manager should identify security dependencies, assign accountable owners, track security risks, and ensure that schedule pressure does not silently remove essential controls. A product owner should prioritize security work alongside functional work. Security professionals should advise and enable delivery rather than act only as a final gatekeeper.

4. DevSecOps

DevSecOps extends DevOps by making security a shared, continuous responsibility across development, security, operations, and business teams. Its goal is not merely to add more tools to a pipeline. It changes working practices so that security feedback is rapid, automated where appropriate, risk-based, and connected to remediation.

A mature DevSecOps capability commonly includes:

• security requirements in product backlogs;
• reusable secure architecture patterns;
• automated build and test pipelines;
• protected source-code repositories and branch controls;
• static application security testing (SAST);
• software composition analysis (SCA) for third-party dependencies;
• secrets detection and secure secret storage;
• infrastructure-as-code scanning;
• dynamic application security testing (DAST);
• container and image scanning where applicable;
• manual review for high-risk functionality;
• production monitoring and feedback into development.

Automation must be governed. A scanner can produce false positives, miss business-logic flaws, or encourage teams to focus on measurable findings rather than material risk. Findings should be triaged by severity, exploitability, exposure, affected asset, compensating controls, and remediation cost. Critical controls should have escalation and exception procedures.

A secure pipeline should protect the pipeline itself. Build systems, signing keys, runners, artifacts, and deployment credentials are high-value targets. Access should be least privileged, actions should be logged, and releases should be reproducible or at least traceable to approved source, dependencies, and build processes.

5. Threat Modeling

Threat modeling is a structured method for anticipating how a system could be misused or attacked. It is most valuable early, when architecture can still be changed economically, but it should be revisited after major changes.

A practical process is:

1. Define the system, business purpose, users, assets, and assumptions.
2. Draw a data-flow or architecture model showing components, data stores, external entities, and trust boundaries.
3. Identify threats using a framework such as STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
4. Analyze attack paths, weaknesses, existing controls, and likely consequences.
5. Prioritize threats and define mitigations.
6. Record owners, decisions, residual risk, and verification methods.

Threat modeling should include legitimate users who make mistakes, malicious insiders, external attackers, compromised suppliers, and failures caused by configuration or dependency changes. It should also consider privacy threats such as excessive collection, unauthorized inference, and inability to exercise data rights.

Example of Threat Prioritization

Suppose an online payment service has a threat involving unauthorized modification of payment instructions. The analysis identifies a high-value asset, an exposed application interface, inadequate authorization checks, and a severe financial impact. Mitigations may include transaction-level authorization, server-side validation, strong audit trails, anomaly detection, and independent security testing.

The objective is not to produce a long list of hypothetical threats. It is to make important assumptions visible and ensure that design decisions address credible attack paths.

6. Secure Coding Governance

Secure coding governance establishes the organizational conditions under which developers can consistently produce safer software. It includes standards, training, review, tooling, accountability, and feedback.

Core practices include:

• validate input on the server and use allowlists where feasible;
• encode output according to its context to reduce injection and cross-site scripting risks;
• use parameterized queries rather than constructing database commands from untrusted strings;
• enforce authorization on every protected operation, not merely in the user interface;
• use secure session management and appropriate cookie protections;
• apply cryptography through approved, maintained libraries rather than custom algorithms;
• avoid storing secrets in source code, logs, or client-side applications;
• fail safely without exposing sensitive diagnostic information;
• minimize data collection and retention;
• handle errors consistently and log security-relevant events without logging secrets;
• keep dependencies current and remove unnecessary components.

Code review should examine business logic, authorization boundaries, error handling, data flows, and dependency behavior—not only formatting. Developers need practical education using the languages and frameworks they actually use. Security champions embedded in development teams can improve communication, but they do not replace specialist review for high-risk systems.

7. Application Security Testing

No single testing method detects every weakness. Effective assurance combines complementary techniques.

Testing should be risk-based. A public authentication service, medical-record system, or payment application deserves more extensive assurance than a low-impact internal prototype. Test environments must be representative enough to reveal security problems while protecting real data. Production data should not be copied into test environments without strong justification and safeguards.

Acceptance criteria should include security conditions. A release may require that no unaccepted critical vulnerabilities remain, high-risk findings have approved treatment plans, logging is operational, default credentials are removed, backup and rollback procedures are tested, and privacy documentation is complete.

8. Change Management and Release Governance

Change management reduces the possibility that an apparently minor modification introduces unacceptable risk. A change record should describe the purpose, affected components, dependencies, security impact, testing, approvals, implementation window, monitoring, and rollback plan.

Changes can be categorized as standard, normal, emergency, or high risk. Standard changes are repeatable and preauthorized under defined conditions. Emergency changes may be necessary to address active exploitation, but they still require retrospective review and evidence. Segregation of duties is valuable: the person who develops a high-risk change should not be the sole person approving and deploying it.

Release governance should avoid both extremes: uncontrolled deployment and bureaucratic delay. Risk-based approval, automated evidence, feature flags, canary releases, and tested rollback procedures can support both speed and control. A change is not complete when code is deployed; monitoring must confirm that the system behaves securely in its real environment.

9. Software Supply-Chain Assurance

Modern applications are assembled from commercial products, open-source libraries, cloud services, APIs, containers, build tools, and managed platforms. This creates a software supply chain in which an organization may inherit vulnerabilities or malicious modifications from parties it does not directly control.

Supply-chain assurance includes:

• maintaining an inventory of direct and transitive dependencies;
• recording versions, licenses, maintainers, and support status;
• obtaining components from trusted repositories;
• verifying integrity through cryptographic hashes or signatures where appropriate;
• producing and reviewing a software bill of materials (SBOM);
• scanning dependencies for known vulnerabilities and exploitability;
• controlling build environments and artifact repositories;
• signing releases and verifying signatures;
• limiting build and deployment privileges;
• monitoring supplier advisories and component health;
• planning replacement for abandoned or single-maintainer components;
• testing the organization’s response to a compromised dependency.

An SBOM improves visibility but is not itself a security guarantee. A listed component may be vulnerable, safely isolated, incorrectly identified, or vulnerable only under particular usage conditions. Conversely, a component may have an undisclosed weakness. Supply-chain decisions therefore require technical analysis, supplier governance, and continuous monitoring.

Open-source software is neither inherently insecure nor automatically safe. Its benefits include transparency, reuse, and community review; its risks include dependency complexity, maintainer compromise, license obligations, and uneven maintenance. Organizations should establish an approved-component process and avoid unsupported assumptions based solely on popularity.

10. Ethical, Legal, and Governance Considerations

Secure development affects people beyond the project team. Weak authentication may expose individuals to identity theft; excessive monitoring may violate privacy; discriminatory algorithms may produce unequal outcomes; and insecure medical or industrial systems may create safety risks.

Professionals should apply data minimization, purpose limitation, transparency, accessibility, and accountability. Security testing must be authorized and conducted within defined scope. Vulnerabilities discovered in third-party products should be reported responsibly, avoiding unnecessary disclosure that increases harm.

Legal and regulatory requirements vary by jurisdiction and sector. They may concern privacy, breach notification, records retention, payment security, accessibility, critical infrastructure, software liability, export controls, and contractual assurance. Compliance is a baseline, not a complete security strategy. Managers must understand which obligations apply, document decisions, and obtain qualified legal advice where necessary.

Artificial intelligence can assist code generation, test creation, vulnerability triage, and anomaly analysis. However, generated code may contain insecure patterns, license problems, hidden dependencies, or inaccurate explanations. Organizations should require human review, approved tools, protection of confidential prompts and source code, testing of generated artifacts, and clear accountability. AI assistance does not transfer responsibility from the organization or developer.

11. Illustrative Case: University Research Data Platform

Background

A university plans a cloud-hosted platform for researchers to upload datasets, collaborate with external partners, and publish selected results. Some datasets contain personal information and confidential agreements.

Problem

The initial proposal emphasizes rapid delivery and assumes that the cloud provider’s general security certification is sufficient. Researchers request broad sharing privileges, developers plan to use numerous open-source packages, and the project has no formal threat model or release security criteria.

Analysis

The platform has several high-impact assets: personal data, unpublished research, credentials, and institutional intellectual property. Important threats include account takeover, excessive partner access, accidental public exposure, malicious file upload, dependency compromise, and inadequate deletion when a project ends.

The provider’s certification offers useful assurance about selected controls, but it does not establish that the university has configured identity, storage, logging, retention, and sharing correctly. Responsibility is divided between the provider and the university.

Approach and Solution

The university establishes a security product owner and conducts a data classification and threat-modeling workshop. Requirements include multifactor authentication for privileged users, role- and project-based authorization, malware scanning, encryption, immutable audit logging, data-retention rules, and approval for external sharing.

The development team uses a protected repository, dependency inventory, automated secret detection, SAST and SCA checks, and peer review. High-risk findings require remediation or documented risk acceptance. Infrastructure is represented as code and reviewed before deployment. A pilot environment uses synthetic data, and a penetration test examines sharing, authorization, and file-upload controls.

The contract requires incident cooperation, supplier notification, access to assurance evidence, subcontractor disclosure, defined support periods, and secure data deletion at exit. A staged release begins with a small research group, with monitoring and rollback procedures in place.

Outcome

Testing discovers that a user interface restriction is not enforced by the server for one sharing endpoint. The defect is corrected before production. A dependency alert later identifies a vulnerable package; the inventory allows the team to determine whether the affected function is used and to patch quickly. The platform is approved with residual risks documented and assigned.

Learning Points

1. Supplier assurance does not replace customer configuration and governance.
2. Threat modeling exposes authorization and data-sharing risks before deployment.
3. Dependency inventory enables faster vulnerability response.
4. Security acceptance criteria make release decisions explicit.
5. Staged deployment provides operational evidence and limits potential harm.

12. Challenges and Best Practices

Common challenges include delivery pressure, unclear ownership, tool fatigue, shortage of security expertise, legacy integration, supplier opacity, and difficulty measuring prevention. Organizations may also mistake compliance evidence for actual risk reduction.

Effective practices include:

• assign security accountability at project initiation;
• make security requirements testable and traceable;
• use threat modeling before major architecture decisions;
• automate repeatable checks while retaining expert judgment;
• protect source, build, artifact, and deployment infrastructure;
• maintain dependency and asset inventories;
• prioritize remediation by business risk rather than scanner count;
• use independent review for high-impact systems;
• document accepted residual risk and its owner;
• measure outcomes such as remediation time, recurrence, coverage of critical assets, and effectiveness of controls;
• learn from incidents, near misses, and escaped defects.

Security metrics require interpretation. A rise in reported vulnerabilities may indicate improved discovery rather than deteriorating security. Similarly, low defect counts may indicate weak testing. Metrics should therefore be combined with qualitative review and evidence of control effectiveness.

Chapter Summary

Secure systems acquisition and development treats security as a lifecycle responsibility rather than a final inspection activity. Procurement should classify information, define measurable requirements, assess suppliers, and establish contractual protections. The SDLC should integrate security into planning, requirements, architecture, coding, testing, release, operation, and retirement.

DevSecOps embeds security into collaborative and automated delivery practices, while threat modeling identifies credible attack paths and supports proportionate design decisions. Secure coding governance combines standards, training, review, tooling, and accountability. Application assurance requires complementary testing methods, risk-based acceptance, and expert judgment. Change management protects the integrity of releases, and software supply-chain assurance addresses dependencies, build systems, suppliers, artifacts, and component inventories.

Ethical and legal responsibilities require protection of privacy, safety, fairness, and accountability. AI can support development but does not remove the need for human review. The central professional principle is that security decisions should be explicit, evidence-based, owned, and revisited as systems and threats change.

Key Terms

Application security: Protection of software applications from unauthorized access, misuse, alteration, and disruption.

Bill of materials: An inventory of components included in a software product.

Change management: A controlled process for assessing, approving, implementing, and reviewing system changes.

DevSecOps: Integration of security into collaborative, automated development and operations practices.

Dynamic application security testing: Testing a running application for security weaknesses.

Expected loss: Probability of an event multiplied by its resulting loss under stated assumptions.

Least privilege: Granting only the access needed to perform an authorized task.

Penetration testing: Authorized adversarial testing designed to identify exploitable weaknesses.

Residual risk: Risk remaining after controls are applied.

Risk acceptance: A documented decision to retain a known risk under defined authority.

Secure SDLC: A development lifecycle with security activities integrated into every relevant stage.

Secure coding: Programming practices intended to prevent vulnerabilities and unsafe behavior.

Software composition analysis: Examination of software dependencies for vulnerabilities, licensing, and maintenance concerns.

Software supply chain: People, processes, tools, components, and suppliers involved in producing and delivering software.

Static application security testing: Analysis of source, bytecode, or compiled code without executing the application.

Threat modeling: Structured identification and treatment of threats to a system.

Trust boundary: A point where data or control moves between different levels of trust.

Vulnerability: A weakness that can be exploited to cause harm or violate a security property.

Review Questions

Short Answer Questions

1. Why should security requirements be defined before implementation?
2. What is the purpose of threat modeling?
3. How does DevSecOps differ from adding a final security test to a project?
4. What information can an SBOM provide?
5. Why is supplier certification not sufficient evidence of secure implementation?

Long Answer Questions

1. Explain how security activities can be integrated into each stage of the SDLC.
2. Compare SAST, DAST, SCA, penetration testing, and manual review, including their limitations.
3. Discuss the role of contracts in managing supplier and cloud-service security.
4. Explain how change management can support both security and delivery speed.
5. Analyze the ethical and governance responsibilities involved in using AI-generated code.

Analytical / Application Questions

1. Design a threat-modeling plan for a mobile banking application. Identify assets, trust boundaries, threats, mitigations, and evidence required for release.
2. A supplier refuses to disclose its subcontractors and provides no vulnerability-notification commitment. Evaluate the risks and recommend procurement conditions.
3. A critical dependency vulnerability is announced during a release freeze. Propose a decision process covering technical analysis, emergency change, communication, deployment, and post-change review.

Multiple Choice Questions with Answers

Question 1

Which activity is most appropriate during the requirements stage of a secure SDLC?

A. Define security and privacy requirements that can be tested

B. Retire the system and destroy all records

C. Perform only post-release penetration testing

D. Replace all functional requirements with security controls

Correct Answer: A. Define security and privacy requirements that can be tested

Question 2

What is the primary purpose of threat modeling?

A. To guarantee that a system has no vulnerabilities

B. To identify credible threats and guide risk treatment

C. To eliminate the need for application testing

D. To select the cheapest software supplier

Correct Answer: B. To identify credible threats and guide risk treatment

Question 3

Which practice best protects against SQL injection?

A. Hiding database error messages only

B. Using longer passwords for database administrators

C. Using parameterized queries

D. Disabling application logging

Correct Answer: C. Using parameterized queries

Question 4

What does software composition analysis primarily examine?

A. The physical security of a data center

B. Third-party and open-source dependencies

C. The usability of a user interface

D. The salaries of development personnel

Correct Answer: B. Third-party and open-source dependencies

Question 5

Why is an SBOM useful?

A. It proves that every component is vulnerability-free

B. It provides visibility into software components and dependencies

C. It replaces access control testing

D. It prevents all malicious supplier behavior

Correct Answer: B. It provides visibility into software components and dependencies

Question 6

Which statement best describes DevSecOps?

A. Security is performed only by an external audit team

B. Security is integrated into development and operations activities

C. Development stops until every theoretical threat is eliminated

D. Operations staff are excluded from security decisions

Correct Answer: B. Security is integrated into development and operations activities

Question 7

A change record should normally include which item?

A. Only the developer’s personal opinion

B. The purpose, affected components, testing, approval, and rollback plan

C. A guarantee that no future change will be needed

D. The removal of all monitoring after deployment

Correct Answer: B. The purpose, affected components, testing, approval, and rollback plan

Question 8

Which testing method examines a running application from an external perspective?

A. DAST

B. SAST

C. Source-code formatting

D. License review only

Correct Answer: A. DAST

Question 9

If an event has probability 0.2 and estimated loss of $50,000, what is the expected loss under the stated simple model?

A. $2,500

B. $10,000

C. $50,200

D. $250,000

Correct Answer: B. $10,000

Question 10

Which procurement clause most directly supports secure contract exit?

A. A requirement for colorful product documentation

B. A requirement that data be returned or securely destroyed

C. A prohibition on all system monitoring

D. A guarantee that the supplier will never change its product

Correct Answer: B. A requirement that data be returned or securely destroyed