Software Development Security:

Assignment 1
Submission Date: 10-08-2025

1. What are common sources of software insecurity?

Software insecurity arises from a combination of technical mistakes, procedural

shortcomings, and flawed assumptions made throughout the development lifecycle. These
sources can be broadly categorized as follows:

●​ Flawed Requirements and Design: Insecurity often begins at the earliest stages.
When security requirements are neglected or treated as an afterthought, the
foundation of the software is weak. A significant portion of security
vulnerabilities—approximately 50%—are attributable to flaws in the software's
architecture and design, which are far more difficult and costly to fix than simple
coding bugs.
●​ Implementation Bugs (Coding Errors): This is a well-known source of
vulnerabilities. Common coding errors that lead to security exploits include:
○​ Buffer Overflows: Writing more data to a buffer than it can hold, which can
allow an attacker to overwrite memory and execute malicious code.
○​ Incorrect Input Validation: Trusting user-provided data is a frequent
mistake. Flaws like SQL injection and cross-site scripting occur when an
application fails to properly sanitize input.
○​ Race Conditions: These occur when the output of the software depends on
the uncontrolled sequence or timing of other events, which can be
manipulated by an attacker.
○​ Poor Exception Handling: When a system fails or encounters an error, it
can enter an insecure state, potentially revealing sensitive information or
allowing an attacker to bypass security controls.
●​ Complexity and Integration Issues: Modern software is rarely built from scratch; it
is assembled from numerous components and legacy systems. This complexity
introduces security risks from unintended interactions between components,
inconsistent security policies, and the use of components not designed for their
current operational environment. The larger and more complex a system is, the more
bugs and vulnerabilities it is likely to have.
●​ Lack of Security Training and Awareness: A fundamental source of insecurity is
that developers and project managers are often not trained to think defensively or to
recognize security implications in their work. This lack of a security-conscious culture
is often the root cause of the technical flaws that arise later.
2. Define software assurance and its role in software security.

Software assurance is the justified level of confidence that software is free from
vulnerabilities and that it functions in the intended manner. It encompasses the disciplines of
software reliability, safety, and, crucially,

software security.

The primary objective of software assurance is to be able to trust that software will operate
dependably under all circumstances, including when it is being subjected to intentional,
malicious attacks.

The role of software assurance in software security is to provide a framework for

achieving and validating trustworthiness. Software security is a sub-discipline of software
assurance focused specifically on the software's ability to resist, tolerate, and recover from
events that intentionally threaten its dependability.

Software assurance provides the overarching goal—justified confidence—while software

security practices are the means to achieve that confidence in the face of malicious threats.
A system with a high level of software assurance demonstrates key properties:

●​ Trustworthiness: The software has a minimal number of exploitable vulnerabilities.

●​ Predictable Execution: There is confidence that the software functions as intended
and does not do anything it is not expected to do, even when under attack.
●​ Conformance: The software meets its specified requirements, standards, and
procedures.

In essence, you cannot have true software security without software assurance. Software
assurance sets the standard of proof required to declare a piece of software secure, moving
it from a vague aspiration to a measurable property of the system.

3. List the benefits of detecting software security defects early in the

SDLC.

Detecting and correcting software security defects early in the Software Development Life
Cycle (SDLC) provides significant benefits in terms of cost, schedule, and overall product
quality.

●​ Massive Cost Savings: The primary benefit is financial. The cost to fix a defect
grows exponentially the later it is found in the SDLC. Reworking a requirements
defect once a system is operational can cost​
50 to 200 times more than fixing it during the requirements phase itself. By investing
in early detection activities, organizations avoid these massive downstream costs.
●​ Reduced Development Time: Contrary to the belief that adding security practices
slows down development, focusing on quality early actually shortens schedules.
Projects with lower defect rates consistently have shorter development times
because less time is spent on rework. Poor quality is a leading cause of schedule
 overruns, as 40-50% of the total cost of software development is typically spent on
reworking avoidable defects.
●​ Improved Product Security and Quality: Finding and fixing security flaws early
naturally leads to a more robust and secure final product. This prevents the
reputational damage, customer loss, and potential legal liability that can result from a
security breach in a released product.
●​ Higher Return on Investment (ROI): Studies have quantified the financial benefits
of early intervention. The ROI for introducing security analysis and secure
engineering practices early in the development cycle ranges from​
12% to 21%, with the highest return occurring when security analysis is performed
during the application design phase.

4. Identify the primary problem with software security.

The primary problem with software security is that it is fundamentally an

organizational and cultural issue, not a purely technical one. While software
vulnerabilities manifest as technical bugs and design flaws, their root cause is often the
failure of organizations to integrate security into the culture and processes of software
development from the very beginning.

For decades, the prevailing approach was "secure the perimeter," focusing on network
firewalls and other operational defenses. This approach is no longer effective because
attackers now target the application layer directly, exploiting the vulnerabilities within the
software itself. The core issues that stem from this cultural problem include:

●​ Security as an Afterthought: Security is frequently treated as a feature to be

"bolted on" late in the development cycle, or as a problem to be handled by testing
just before release. This is far less effective and exponentially more expensive than
building security in from the start.
●​ Lack of Security Goals and Vision: Many organizations lack a clear,
executive-sponsored vision for software security. Without this top-down mandate,
security efforts often fail due to political infighting, budget battles, and a lack of clear
roles and responsibilities.
●​ Flawed Requirements Process: The security problem often begins at the
requirements stage, where security needs are overlooked, poorly defined, or not
tailored to the specific system, and the attacker's perspective is not considered.
●​ Focus on Features over Properties: Developers are trained to build
functionality—what the software should do. Security, however, is an emergent
property that is also concerned with what the software​
should not do, especially when under attack. This requires a different mindset that is
often lacking.

In short, the myriad of technical vulnerabilities we see today are symptoms of a deeper,
systemic problem: a development culture that has not yet fully embraced security as an
essential, non-negotiable component of software quality.
5. Explain why security is considered a software issue.

Security is considered a software issue because modern digital infrastructure and services
are built on and controlled by software, and it is the vulnerabilities within this software that
have become the primary target for attackers. The focus of security has shifted from the
network to the application itself.

Here's a breakdown of why this shift has occurred:

1.​ Software is Ubiquitous and Critical: Software runs everything from our phones and
cars to our banking systems and critical infrastructure like the power grid. This
dependence makes software an extremely high-value target for criminals, terrorists,
and other adversaries.
2.​ Increased Connectivity and Exposure: The vast majority of these software
systems are connected to the Internet, which exposes them to a global pool of
potential attackers. This constant exposure means that any vulnerability is likely to be
discovered and exploited.
3.​ Attackers Exploit Software Flaws: The security of a computer system is now
fundamentally limited by the security of its software. Attackers are no longer primarily
trying to breach network firewalls; they are sending cleverly crafted inputs to
applications to exploit common software defects like buffer overflows, SQL injection,
and flawed business logic.
4.​ Perimeter Defenses are Insufficient: Relying on network-level protections like
firewalls is an outdated and ineffective strategy. This approach fails because it does
nothing to address the vulnerabilities within the application software itself.
Furthermore, these protective mechanisms can be misconfigured or contain their
own exploitable flaws. An attacker who can get a malicious request through a firewall
will find a vulnerable application waiting.

Essentially, the battleground has moved inside the digital infrastructure, to the software that
handles our most sensitive information and controls our most critical processes. Therefore,
building secure systems requires building secure software.

6. Describe the relationship between defect rates and development time.

The relationship between software defect rates and development time is that

higher quality in the form of lower defect rates goes hand-in-hand with reduced
development time. Projects that successfully reduce their number of defects typically finish
faster, while projects with poor quality are frequently late.

This relationship can be visualized as a U-shaped curve:

●​ High Defect Rates Lead to Longer Schedules: On the left side of the curve, where
pre-release defect removal is low, development time is high. This is because a large
 number of defects escape into later stages, requiring significant and costly rework
that delays the schedule.
●​ The Optimal Point: The bottom of the curve represents the optimal balance, where
development time is minimized. This "sweet spot" occurs at a high level of
pre-release defect removal (around 95%), resulting in the shortest possible schedule.
●​ The Cost of Perfection: On the far right side, as defect removal approaches 100%,
development time increases again. This reflects the law of diminishing returns;
finding and fixing the last, most obscure defects requires a disproportionately large
amount of effort.

Most organizations operate to the left of the optimal point, with higher defect rates and
longer schedules than necessary. The key takeaway is that investing in quality practices to
reduce defects is a core strategy for achieving a faster development schedule.

7. Summarize the impact of compressing the testing schedule on

software security.

Compressing the testing schedule in an attempt to save time or money has a direct and
negative impact on software security. It leads to lower-quality software with more
vulnerabilities and can paradoxically result in longer overall development times.

The key impacts are:

●​ Increased Number of Defects: Testing is a primary method for finding and removing
defects. Cutting this phase short directly translates to more bugs and flaws remaining
in the released product. Since many of these defects are exploitable security
vulnerabilities, a compressed testing schedule results in less secure software.
●​ Higher Risk of Catastrophic Vulnerabilities: Projects developed under excessive
schedule pressure are known to have up to four times the average number of
defects. This significantly increases the likelihood that a critical security vulnerability
will be missed and later discovered by an attacker.
●​ False Economy of Time: While it seems like shortening the testing phase will
shorten the overall schedule, it often has the opposite effect. Defects that are missed
during testing are simply postponed. When these defects are inevitably found by
users or attackers after release, they are far more time-consuming and expensive to
fix, involving emergency patches and significant developer effort that disrupts new
work.

In summary, compressing the testing schedule is a high-risk gamble that trades a short-term,
visible schedule gain for a long-term, hidden cost in security, quality, and overall project
efficiency.

8. Illustrate the significance of the "95 percent defect removal" line.

The "95 percent defect removal" line is significant because it represents the
optimal point of efficiency for a software project. It is the level of pre-release quality at
which projects achieve the

shortest possible development schedules for the least amount of effort, while also
delivering a product with the highest levels of user satisfaction.

Here is an illustration of its significance:

●​ Project A (Typical Approach - Below 95%): This team operates to the left of the
95% line, removing about 85% of defects before release. The released product is
buggy. The team spends the next several months in a reactive "fire-fighting" mode,
creating numerous patches. The total time to a stable product is 18 months.
●​ Project B (Optimal Approach - At 95%): This team invests in better quality
practices and operates at the 95% defect removal line. The released product is highly
stable and secure. The total time to a stable product is only 12 months.

The significance of the 95% line is that it marks the turning point:

●​ Below 95%: Projects are inefficient. They spend too much time and money on
rework, leading to longer schedules and lower quality products. Most organizations
fall into this category.
●​ At 95%: This is the "sweet spot." The investment in quality pays for itself by
minimizing costly rework, resulting in the fastest possible time-to-market for a
high-quality product.
●​ Above 95%: Striving for perfection becomes inefficient. The effort required to find
and fix the last few, very obscure defects increases development time again due to
diminishing returns.

Therefore, the 95% line illustrates that focusing on high quality is not an impediment to
speed but is, in fact, the most direct path to achieving it.

9. Apply the concept of early defect detection to explain its cost-saving

potential.

The concept of early defect detection is one of the most powerful economic principles in
software engineering. Its cost-saving potential stems from the fact that

the cost to fix a software defect increases exponentially the later it is discovered in
the SDLC. Applying this concept means investing in quality assurance activities at the very
beginning of a project to avoid massive costs later on.

Let's apply this with a practical example:

Scenario: An architect makes a mistake in the design of an authentication system for a new
banking application.

●​ Case 1: Early Detection (Low Cost)

 ○​ Phase: Architecture & Design
○​ Detection Method: A security-focused design review identifies the logical
flaw in the design diagrams.
○​ Correction: The architect spends two hours updating the design document.
○​ Total Cost: The cost of a few hours of the architect's and reviewer's time,
perhaps $500.
●​ Case 2: Late Detection (High Cost)
○​ Phase: Post-Release / Operations
○​ Detection Method: One year after deployment, an attacker exploits the
vulnerability, stealing funds.
○​ Correction: Fixing the flaw is now a complex, emergency operation involving
investigation, coding, rigorous testing, emergency patch deployment, and
updating all related documentation.
○​ Total Cost: The direct cost could be tens of thousands of dollars in staff time.
The true cost includes regulatory fines for the data breach, loss of customer
trust, and potential lawsuits, potentially running into the millions of dollars.

As this example shows, the cost multiplier is enormous. Studies confirm this, finding that
fixing a requirements defect in an operational system can cost

50 to 200 times more than fixing it during the requirements phase itself. By investing in
early detection, organizations realize immense cost savings by avoiding this exponential
inflation of repair costs.

10. How would you integrate security practices into the SDLC to
enhance software security?

Integrating security practices into the SDLC involves embedding specific security-focused
activities, or "touchpoints," into each phase of an existing development process. The goal is
to build security in from the start.

Here is a phase-by-phase breakdown of how security practices can be integrated:

1.​ Requirements and Use Cases:

○​ Practice: Elicit and define explicit Security Requirements.
○​ Practice: Develop Abuse and Misuse Cases to brainstorm how an attacker
might abuse a feature.
2.​ Architecture and Design:
○​ Practice: Perform an Architectural Risk Analysis (Threat Modeling) to
systematically identify threats and design flaws before coding begins.
○​ Practice: Apply Security Principles like "Least Privilege" and "Defense in
Depth" to create a more robust architecture.
3.​ Implementation (Coding):
○​ Practice: Conduct Secure Code Reviews using automated static analysis
tools combined with manual peer reviews to find common vulnerabilities.
 ○​ Practice: Adhere to Secure Coding Standards to help developers avoid
common pitfalls.
4.​ Testing and Quality Assurance:
○​ Practice: Implement Risk-Based Security Testing to actively try to break
the software's security mechanisms, guided by the risks identified during
threat modeling.
○​ Practice: Perform Penetration Testing to simulate a real-world attack on the
application, often just before or after deployment.
5.​ Deployment and Operations:
○​ Practice: Harden the deployment environment and establish Security
Operations, including secure configuration, monitoring, and incident
response planning.

By weaving these practices into the existing SDLC, security becomes an integral part of the
software quality process, leading to a more secure and resilient final product.

11. Demonstrate how a risk management framework can be used to

manage software security risks.

A Risk Management Framework (RMF) provides a structured, continuous process for

identifying, prioritizing, and mitigating security risks throughout the software development
lifecycle.

Here is a demonstration of how the five-stage RMF can be used to manage a specific
software security risk:

Scenario: A development team is building a new e-commerce website.

Stage 1: Understand the Business Context The team identifies key business goals:
protect customer privacy and financial data to maintain trust and comply with regulations like
PCI DSS. This context is critical for evaluating technical risks in terms of their business
impact.

Stage 2: Identify Business and Technical Risks The team performs an architectural risk
analysis and identifies a technical risk: the design involves building SQL queries by
concatenating strings with user input. They link this to a major business risk: an attacker
could exploit this

SQL Injection flaw to steal the customer database, leading to massive financial loss and
brand damage.

Stage 3: Synthesize and Prioritize Risks The team has identified several risks. Using the
business context from Stage 1, they prioritize them. The SQL injection vulnerability is ranked
as

Critical because its likelihood is high and its business impact is extreme. This ensures that
the most important problems are addressed first.
Stage 4: Define the Risk Mitigation Strategy For the critical SQL injection risk, the team
defines a clear mitigation strategy:

●​ Correction: The development team will refactor the code to use parameterized
queries (prepared statements).
●​ Validation: The QA team will develop specific security test cases to verify that the fix
is effective.

Stage 5: Carry Out Fixes and Validate The developers implement the code changes. The
QA team then executes their security tests, confirming that the application now rejects
malicious SQL input and the vulnerability has been closed. The risk is documented as
"Mitigated".

This framework is a closed-loop, continuous process that will be applied throughout the
SDLC to manage new risks as they emerge.

12. Use an example to show how error-prone modules can affect

software development.

Error-prone modules are parts of a software system responsible for a disproportionate

number of defects. Statistics show that 20% of modules can be responsible for 80% of the
errors. These modules act as a major drain on a project, negatively affecting cost, schedule,
and quality.

Here is an example:

Scenario: A company is developing an office suite. The "DocumentCollaboration"

module, for real-time multi-user editing, is highly complex and becomes error-prone.

Effects on Software Development:

●​ Increased Cost and Schedule Overruns: The DocumentCollaboration module is far

more expensive to complete than any other part of the suite. Normal modules cost
~$500-1000 per function point, but rework drives this module's cost to​
$2000-$4000 per function point. The team spends more time fixing bugs in this
module than developing new features, causing a​
three-month schedule slip for the entire product launch.
●​ Decreased Overall Quality and Security: The module is the source of most
customer complaints, including crashes and data loss. Its instability also makes it a
security risk. A bug in its network code creates a race condition that an attacker
exploits, allowing unauthorized access to private documents. The team must issue
an emergency security patch, damaging the product's reputation.
●​ Drain on Team Morale and Resources: The company's best developers are
constantly pulled off of innovative work to fix problems in the error-prone module.
This slows progress and leads to developer burnout.
In this example, the single error-prone module dragged down the entire project. Identifying it
as error-prone early and redesigning it would have been a high-priority, cost-saving action.