Please enable JavaScript.
Coggle requires JavaScript to display documents.
DOMAIN 8: SOFTWARE DEVELOPMENT SECURITY - Coggle Diagram
DOMAIN 8: SOFTWARE DEVELOPMENT SECURITY
8.1 Understand and integrate security in the software development life cycle (SDLC)
8.1.1 Security’s Involvement in Development
CORE CONCEPTS
Security should be involved at every phase of the development life cycle.
8.1.2 SDLC and SLC
CORE CONCEPTS
Security should be considered at every phase of SDLC/SLC.
-
Risk analysis and threat modeling are very important components of the early phases of SDLC/SLC.
-
Testing should include static, dynamic, and fuzz (a form of dynamic testing) tests.
-
Certification and accreditation should be performed prior to release/deployment/implementation.
Development and Maintenance Life Cycle
The “
Waterfall
” Development Model:
8.1.3 Development Methodologies
CORE CONCEPTS
Development methodologies exist for the sake of efficient and effective code development.
-
Many methodologies are a reflection of the waterfall methodology.
-
Regardless of the methodology, security should be considered at every stage of the development process.
-
Methodologies can be combined to utilize the best features of each of them.
-
Agile scrum masters understand how all team efforts fit together and can therefore effectively and efficiently lead activities.
Waterfall versus Agile
Agile Scrum Master
With Agile, each team works very closely and in a very time efficient manner, while all of the team’s efforts are coordinated by a person known as the Scrum Master.
Scrum Masters are typically hyperfocused on completing tasks as quickly as possible and hopefully not at the expense of security. Other advantages of having a Scrum Master include the following:
Shields team from external interference
-
Enforces scrum principles
-
Facilitator and removes barriers
-
Enables close cooperation
-
Improves productivity
8.1.4 Maturity Models
CORE CONCEPTS
Like development methodologies, maturity models also help improve the development process.
-
Capability Maturity Model Integration (CMMI) is one of the most popular models and includes six levels of maturity: incomplete, initial, managed, defined, qualitatively managed, optimizing.
-
Each level of maturity of the CMMI is defined by certain characteristics.
CMMI includes six maturity levels
Software Assurance Maturity Model
SAMM consists of three maturity levels:
Level 1—Initial Implementation
-
Level 2—Structured Realization
-
Level 3—Optimized Operation
SAMM looks at software assurance from the high-level perspective of five business functions:
Governance
Design
Implementation
Verification
Operations
Operation and Maintenance
The success of software development is not pinned to the release of an application to production. In fact, it could be argued that long-term successful—and secure—software releases happen as a result of ongoing operation and maintenance that includes monitoring, periodic evaluation, and patching.
8.1.5 DevOps
CORE CONCEPTS
An integrated product team is really a fancy term for DevOps: software development, operations, quality assurance (QA).
-
Ideally, DevOps should include security as an integral part of the development process and be referred to as DevSecOps.
Integrated Product Team (IPT)
An integrated product team (
IPT
) is a team of skilled professionals who each bring specific expertise and skills to a development project.
At its core, the IPT is a fancy name for DevOps, a software development approach that aims to unify:
Software development
Operations
Quality assurance
DevOps brings together members from all relevant areas at the start of a project to improve collaboration, agility, and efficiency. This approach avoids the problems of siloed teams—like poor coordination and late-stage security—and ensures shared goals from the outset.
DevOps Security
Know when security should be involved with DevOps.
Many traditional security techniques, for example, items like penetration tests, security analysis, and so on are too slow for rapid iteration of DevOps.
However, DevOps should ideally be referred to as DevSecOps, or even better, SecDevOps. This is where security is an integral part of the development process.
Incorporating security into DevOps should include the following components and approach:
Plan for security
Strong engagement between developers, operations, and security
Engage developers
Develop using secure techniques and frameworks - Automate security testing, for example, using a robust CI/CD pipeline
Use traditional techniques sparingly
Combining Development Methodologies
Many organizations combine methodologies to suit their specific needs, and this approach can work with DevSecOps.
8.1.6 Canary Testing and Deployments
CORE CONCEPTS
Canary testing and deployments refer to hyperfocused testing of new application code/features by pushing out the changes to a small subset of users versus pushing out to all users.
-
Smoke Testing
Another commonly used type of testing in software development. Smoke testing focuses on quick preliminary testing after a change is made to identify any simple failures of the most important existing functionality that worked before the change was made.
8.2 Identify and apply security controls in software development ecosystems
8.2.1 Software Development Overview
Programming Languages
: Evolved from low-level (machine/assembly) to high-level (structured, object-oriented) and now to natural languages (like Prolog). Many legacy apps still use older languages like COBOL.
-
Libraries
: Collections of reusable code/resources.
Static libraries are linked at build time.
Dynamic (runtime) libraries are loaded when the program runs.
-
Tool Sets / SDKs
: Bundled compilers, debuggers, APIs, and frameworks for building apps, often targeted to specific platforms.
-
IDE (Integrated Development Environment)
: All-in-one tool for editing, compiling, debugging, and automating tasks. Examples: Visual Studio, IntelliJ IDEA, Eclipse.
-
Translators
:
Assemblers convert assembly → machine code.
Compilers convert high-level → machine code.
Interpreters convert high-level one line at a time at runtime.
-
Runtime
: Period when code executes.
Modern Practices
CI/CD
: Automates code integration, testing, delivery, and deployment. Faster, safer releases.
-
SCM (Software Configuration Management)
: Manages changes to code, builds, and processes to improve productivity and minimize mistakes.
-
Code Repositories:
Store and version source code (GitHub, SourceForge, etc.), support reviews, bug tracking, and collaboration.
Security & Testing
App Security Testing:
SAST (static / white-box): Examines code.
DAST (dynamic / black-box): Examines running app.
Fuzzing: Random/chaotic input testing.
IAST: Mix of SAST + DAST on running code.
-
Secure Programming Concepts
:
Inheritance
: New code objects inherit properties from existing ones.
-
Encapsulation
: Wrap code to hide/protect details.
-
Polymorphism
: Code changes behavior to fit needs.
-
Polyinstantiation
: Multiple independent instances of something.
-
SecDevOps
: Build security into development from the start with collaboration between business, tech, and security teams.
8.2.2 Code Obfuscation
Code obfuscation is the deliberate act of making source code harder to read or interpret to protect it from unauthorized viewing, reverse engineering, or revealing its true purpose. Instead of changing the program’s functionality, it changes how the code looks or runs so that it becomes confusing to humans.
There are
Three main types
of code obfuscation:
Lexical Obfuscation
– Alters the visible appearance of code by changing comments, removing debugging info, or reformatting. This is the easiest but also the weakest form.
-
Data Obfuscation
– Changes how data structures are represented to hide their intent.
-
Control Flow Obfuscation
– Changes the execution order by reordering statements, methods, loops, or inserting irrelevant conditional statements to make the flow harder to follow.
A significant risk of obfuscation is disaster recovery.
If an application’s only available version is obfuscated, it may be very difficult or impossible to restore or fix quickly. To prevent this, organizations should securely store clean, unaltered source code (e.g., in a software vault) and incorporate this into their Business Continuity Management (BCM) plan.
8.2.3 DBMS, Concurrency, and Lock Controls
CORE CONCEPTS
Components of DBMS include: hardware, software, language (SQL, for example), users, data.
Database terminology: columns/fields = attributes; records/rows = tuples.
Foundation of a relational database is the concept of primary and foreign keys. - Primary keys: one or more columns whose values uniquely identify a tuple (row) within a relational database.
Foreign keys: one or more columns whose values in a table refer to the primary key in another table.
Concurrency: ability for multiple processes to access or change shared data at the same time.
Locks prevent data corruption when multiple users try to write to the database simultaneously.
ACID: atomicity, consistency, isolation, durability.
Relational Databases (RDBMS)
Modern databases are relational, storing data in linked tables.
Columns/Fields = Attributes (each column describes a characteristic).
Records/Rows = Tuples (each row is a single entity).
This structure allows inference and relationships between data.
Primary & Foreign Keys
Primary Key
– One or more columns whose values uniquely identify each row (tuple) in a table.
-
Foreign Key
– One or more columns in a table that reference the primary key in another table.
Together they maintain referential integrity: e.g., every StudentID in a registration table must exist in the student table.
Primary keys must be validated (length, type, uniqueness) when new records are added.
Concurrency & Locks
Concurrency – Multiple processes accessing or changing shared data at the same time.
Locks – Mechanisms that prevent data corruption when multiple users try to write simultaneously. A record locked by User A cannot be edited by User B until released.
ACID Properties
Transactions in RDBMS should follow ACID principles:
Atomicity
– All changes succeed or none do.
-
Consistency
– Database stays consistent with rules and constraints.
-
Isolation
– Transactions are invisible to others until complete.
-
Durability
– Completed changes persist even after system failures.
Security of Database Environments
Because databases drive decisions and hold sensitive data:
Security must exist in all components: hardware, software, tools, user access, and the data itself.
-
Best practice: separate development, test/QA, and production environments.
-
Users must understand usage policies and responsibilities.
-
Applications interacting with databases must also be secured.
8.2.4 Metadata
Metadata = data about data.
Gives information about other data (context, properties, management).
Examples for a file: creation date, last modified date, owner, file size.
8.2.5 Development Ecosystems
Examples: CI/CD (Continuous Integration / Delivery / Deployment), SOAR (Security Orchestration, Automation & Response), SCM (Software Configuration Management).
Each has a different focus but shares key traits:
Automation to ensure consistency and quality.
-
Efficient, effective delivery of products/results.
-
Proactive security focus to protect the organization, partners, and customers.
8.3 Assessing the Effectiveness of Software Security
8.3.1 Software Security Assessment Methods
Goal: Determine how effective software security is.
Key approaches:
Auditing & Logging – Track changes, log and monitor activity.
Risk Analysis & Mitigation – Identify, analyze, and address risks.
Testing & Verification – White box / black box testing, threat modeling, penetration testing.
Internal & External Audits – Independent reviews to ensure compliance.
Procurement Review – Check security before acquiring software.
Certification & Accreditation:
Certification = detailed technical analysis to ensure requirements are met.
Accreditation = management’s official approval to deploy the solution.
Code Signing – Ensure authenticity and integrity of code.
8.4 Assess the Security Impact of Acquired Software
Security always matters
: Buying or outsourcing software development does not remove the need for security assessment. Testing, vulnerability assessment, and security reviews must be included at every stage.
-
Source code access
: Vendors often only deliver compiled products; buyers may request source code escrow to guarantee future access (e.g., if the vendor disappears).
8.4.1 Acquiring Software
Acquiring software should be taken as seriously as developing software, and security should be considered at every step in the process.
-
Software assurance phases for acquisition include: planning/requirements, contracting, acceptance, monitoring and follow-on.
-
Common ways to acquire software is via: COTS, open source, third party, managed services.
Software Assurance Phases for Acquisition
Planning / Requirements
-
Contracting
-
Acceptance
-
Monitoring & Follow-on
COTS (Commercial Off-the-Shelf)
: Widely used, user-friendly, big support communities.
Pros
: Easy to evaluate, compare, and update; third-party reviews available.
-
Cons
: No white box testing, vendor risk, possible missing features, widely probed for vulnerabilities.
Open Source
: Similar to COTS but with open code.
Pros
: Transparency, control, rapid vulnerability fixes, stable communities.
-
Cons
: Must be examined like in-house code; community contributions can introduce vulnerabilities (e.g., OpenSSL “Heartbleed”).
Reasons
:
Control
: the organization can thoroughly examine the code to make sure it is safe, and they can choose to modify or omit parts of the software.
-
Training
: programming students can use open source software as a learning tool and invite feedback and scrutiny from a much wider audience.
-
Security
: due to the “open” nature of open source software, vulnerabilities and issues that may impact the stability of the software are typically identified and corrected much more quickly. Additionally, missing functionality can be added just as quickly.
Third-Party Code / Contractors
:
Hold to same scrutiny and SDLC as any vendor product.
Managed Services (MSPs)
:
Outsourced IT/support or enterprise applications. Assess carefully—review SOC reports, site visits, talk to customers, check regulatory compliance.
Cloud Services (SaaS, IaaS, PaaS)
:
Security must be involved from selection to migration. Understand the shared responsibility model—responsibilities must be clearly written into agreements.
8.5 Secure Coding Guidelines and Standards
8.5.1 Secure Coding Guidelines
Produce consistently secure software by defining and enforcing secure coding guidelines & best practices.
Frameworks/Resources:
OWASP (publishes Top 10 Web Application Security Risks, mitigation guidance).
NIST & CIS secure software development frameworks.
Common Code-Level Security Weaknesses:
Covert Channels
: Unintentional data leakage paths (timing or storage).
-
Buffer Overflows
: Input exceeds allocated storage space.
-
Memory/Object Reuse:
Sensitive data left in memory may be reused by other processes.
-
Executable Mobile Code:
Downloaded code running locally; test in a sandbox first.
-
TOCTOU (Race Conditions)
: Exploiting gaps between “check” and “use” of a value.
-
Backdoors/Trapdoors
: Developer shortcuts left in production code.
-
Malformed Input:
Insufficient input validation (a top OWASP vulnerability).
-
Citizen Developers
: Non-technical users with powerful tools but limited security skills — need policies, training, and awareness.
8.5.2 Buffer Overflow
Definition: Occurs when data
sent to a buffer exceeds its capacity
. Attackers can inject executable code into memory and escalate privileges or execute malicious actions.
Why It Happens: Buffers are fixed in size; applications may not check or limit input properly.
Mitigation Techniques:
ASLR (Address Space Layout Randomization)
: Randomizes memory locations of executables, making it hard for attackers to predict where to inject code.
-
Parameter/Bounds Checking
: Validate input length, types, and array indexes before use.
-
Runtime Checking:
Actively monitor array and buffer boundaries during execution.
-
Safe Languages/Library Functions
: Use programming languages and libraries with built-in bounds checks.
-
Improve SDLC
: Code reviews, secure coding practices, automated testing.
8.5.3 Application Programming Interfaces (APIs)
CORE CONCEPTS
Application programming interfaces (APIs) provide a way for applications to communicate with each other; APIs act as translators.
-
Two of the most common APIs are Representational State Transfer (REST) and Simple Object Access Protocol (SOAP).
-
APIs should be secured along with other components of an application; security can include authentication and authorization mechanisms, TLS encryption for data traversing insecure channels, API gateways, and data validation, among others.
Common Types:
REST
: Newer, lightweight, HTTP-based, easy to use, flexible (outputs CSV, JSON, RSS, XML).
-
SOAP
: Older, XML-based, more rigid but standardized, strong error handling, extensible with WS standards.
API Security Best Practices:
Implement authentication & authorization (OAuth, access tokens).
-
Use encryption (TLS) for data in transit.
-
Perform data validation on all inputs/outputs.
-
Use API gateways to centralize security.
-
Apply quotas & throttling to prevent abuse.
-
Conduct testing & validation regularly.
8.5.4 Secure Coding Practices
CORE CONCEPTS
Secure programming can help prevent software vulnerabilities.
-
Secure coding practices include: input validation, authentication and password management, session management, among others.
-
Coupling and cohesion are relational terms that indicate the level of relatedness between units of a code base (coupling) and the level of relatedness between the code that makes up a unit of code (cohesion).
-
Low coupling (meaning units of code can stand alone) and high cohesion (meaning the code that makes up a unit of code is highly related) are optimal.
-
Polyinstantiation refers to something being instantiated into multiple separate or independent instances and can be used to prevent unauthorized inference.
Goal
: Prevent or minimize software vulnerabilities that attackers can exploit.
Key Practices:
Input validation
Authentication & password management
Session management
Cryptographic practices
Error handling & logging
Secure system configuration
File & database security
Memory management
Coupling & Cohesion
Coupling
: How dependent one unit of code is on another.
-
Cohesion
: How closely related the code within a unit is.
-
Ideal
:
Low coupling
(modules are independent) +
High cohesion
(each module does one well-defined thing).
-
Why
: Improves security, maintainability, and reduces cascading vulnerabilities.
Polyinstantiation
Definition: Having multiple independent instances of the same data for different classification levels.
-
Purpose:
Prevent unauthorized inference
—users at lower clearance levels cannot deduce the existence of higher-classified data.
-
Example: Same “Charlie Company 6” record exists at different classification levels but mapped differently for lower users.
Software-Defined Security (SDS)
-
Definition
: Security implemented, controlled, and managed by software (often in cloud/virtual environments).
-
Examples of SDS functions:
Firewalls, intrusion detection/prevention, access control—all software-instantiated and policy-driven.
-
Benefit
: Flexible, cost-effective, policy-based security aligned with organizational goals.
8.5.5 Software Development Vulnerabilities
CORE CONCEPTS
Insecure coding practices and citizen developers writing code usually leads to software development vulnerabilities.
-
Backdoor/trapdoor attacks often result from software vulnerabilities.
-
Between-the-lines attack = attacker intercepts/modifies communication between devices/people over a network; also known as a man-in-the-middle attack.
Causes
:
Insecure coding practices
-
“Citizen developers” (self-taught, untrained users) writing code without secure practices
Common Results:
Backdoors/trapdoors
– hidden ways to bypass authentication (e.g., leftover developer access).
-
Between-the-lines attacks (MITM)
– attacker intercepts or modifies communications between devices/people over a network.
-
Memory/Object reuse issues
– residual sensitive data from previous operations can be accidentally or intentionally accessed.
Prevention
:
Enforce secure coding guidelines and training.
-
Clear residual data from memory before reuse.
-
Test and review code for backdoors, insecure patterns, and data-handling flaws.
