Applying modern secure software frameworks to ensure secure coding practices during each stage of the software development life cycle (SDLC) can significantly reduce security risks and vulnerabilities in developing software or applications, especially critical zero-day vulnerabilities. These risks and vulnerabilities may include cross-site scripting (XSS), SQL injections, and software tampering when malicious actors install a backdoor into the software code. Startups have the edge over established organizations that lack software frameworks to implement the best approach that fits their needs during the early stages of software development. On the other hand, established organizations may find it more challenging to implement a secure software framework and fix insecure code after releasing software or an application. 

In a survey polling 300 IT and security professionals recently done by Dimensional Research, more than 54% of respondents said their organization knowingly released software with potential security risks. Recently, a team of researchers at Google Project Zero (GPZ) also found 18 zero-day bugs in 2022 linked to poor software fixes which affected Microsoft Windows, Apple iOS and WebKit, Google’s Chromium, Pixel, and Atlassian’s Confluence server. In 2019, Verizon’s Data Breach Report stated that the number-one reason for data breaches is insecure software, causing between 26% and 40% of leaked and stolen records. This year, the report states that web applications are the number one vector of data breaches accounting for between 40% to 60% of breaches.

Companies are taking dangerous risks with their software releases. Insecure software and applications continue to become the top cause of data breaches because many companies do not prioritize the security of their software code and will not set a budget for it, releasing new software that contains vulnerabilities. For example, many companies are now looking to low-code and no-code platforms to build apps in the visual environment for two reasons 1) they save money on hiring developers, and 2) they can develop apps more expeditiously. Less experienced or minimally trained staff without a developer or strong IT background will engage in these low-code and no-code projects. 

Alarmingly, a whopping 98% of respondents in a survey polled by Dimensional Research said that third-party software code, including open-source software, increases supply chain risk. 

Startups can mitigate the security risks of insecure code by utilizing a modern secure software framework. These frameworks include the NIST Secure Software Development Framework (SSDF), BSA Framework for Secure Software, SAFECode Fundamental Practices for Secure Software Development, and the open-source OWASP Security Knowledge Framework (SKF). The OWASP SKF is open-source and uses the OWASP Application Security Verification Standard (ASVS) and OWASP Mobile Application Security Verification (MASVS), which include checklists. Furthermore, the OWASP ASVS is undoubtedly a standard for verifying application security. Lastly, developers must incorporate security in their software development life cycle (SDLC).

Top security risks of insecure code

Insecure software code comes with various security risks and vulnerabilities that malicious actors can exploit. One of the main risks to computer software is when data from users becomes executed as if it were a part of your application’s code. A malicious actor can inject Javascript into your application and run it in the web browser (e.g., XSS) to do more damage. Any input to your software could be tampered with, which is dangerous when not properly filtered or validated. 

The OWASP Top 10 is a regularly updated standard awareness document for developers and web applications globally recognized and lists the most critical security risks to web applications.

OWASP top 10: 2021 web application security risks

• Broken Access Control: Occurs when attackers successfully execute privilege escalation and bypass authorization to access, modify, delete, or perform actions outside of an application’s or system’s intended permissions. 
• Cryptographic Failures: A third-party entity (e.g., web app) exposes sensitive data due to software flaws, weak or no encryption, no hashing and salting of passwords, or HTTPS security not enabled; these can lead to inadequate database protection, inappropriate usage of data systems, or misconfigurations. These vulnerabilities can create the perfect playground for SQL injections and allow attackers to read passwords easily in clear text.
• Injection: When user-supplied data or input is not validated, filtered, or sanitized by the application, or when untrusted data in the form of queries, form fields, headers, or cookies get sent to an interpreter or calls out to a database, an attacker can send the database commands and trick it into performing unwarranted actions the malicious actor wants it to do (rather than what you programmed the instructions to follow). An example is when an attacker injects malicious input called a payload that returns sensitive information and allows the attacker to modify or delete data if they want to. Types of injections include Cross-Site Scripting (XSS) via JavaScript (most common), HTML, ActiveX, or Flash on a vulnerable dynamic web page. Other types are SQL injection, OS command injection, and LDAP injection.

• Insecure Design: The outcome of an insecure design is the direct result of not having 1) a threat model, 2) a secure development lifecycle (SSDLC), and, most importantly, 3) the proper security controls during the planning phase. An organization’s team of developers, security, IT, and quality assurance (QA) can fail to create or anticipate the needed security controls for specific threats. It’s important not to ignore design at the earliest stages of development, as OWASP states that a perfect implementation cannot fix an insecure design. However, a secure design can have implementation defects that lead to exploitable vulnerabilities. That is the significant difference between insecure design and insecure implementation.
• Security Misconfiguration: Security misconfigurations occur from improperly configured settings such as permissions on cloud services. Insufficient security hardening of software or an application can cause security misconfigurations too. Misconfigurations are the #1 security risk for Kubernetes, an open-source platform for containerization management. The top 5 security misconfigurations in Kubernetes containers are: run privileged containers, cluster-admin binding, missing resource policies, immutable container filesystem, Ingress and Egress blocked.
• Vulnerable and Outdated Components: Vulnerable, unsupported, or outdated software, including not knowing all the versions of components used for both the client and server-side (as well as nested dependencies), can create this vulnerability. Software developers must stay up-to-date by testing the compatibility of updated, upgraded, or patched libraries. Not removing unused or unnecessary components, as well as dependencies, features, files, or documentation, can leave room for attackers to silently gain access to them and remain undetected for long periods. An adage fits this scenario well, “What you can’t see won’t hurt,” at least not until it’s too late.
• Identification and Authentication Failures: The use of weak, unencrypted, and default passwords are a few examples of authentication weaknesses. In addition, the lack of two-factor authentication (2FA) implementation can make room for brute force attacks, credential stuffing, and stolen credential reuse attacks. Refer to this post to learn how to implement strong passwords and two-factor authentication.
• Software and Data Integrity Failures: Code and infrastructure that does not protect against integrity violations can create software and data integrity failures. An insecure continuous integration and continuous deployment (CI/CD) pipeline can introduce the potential for unauthorized access, malicious code, or system compromise. An example of code and infrastructure not protecting against integrity violations is when an application relies on other plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). Additionally, auto-updates can occur in applications without sufficient integrity verification and get applied to the previously trusted application. The perfect example of this case is the infamous SolarWinds malicious update which you can read about here.
• Security Logging and Monitoring Failures: Insufficient logging, detection, monitoring, and active response can cause these failures. Logging and monitoring are critical because they help to detect breaches. Logging for events such as successful and failed logins, including suspicious activity, can help detect threats as soon as they occur. Setting alerts for appropriate thresholds and response escalation processes must be in place.
• Server-Side Request Forgery (SSRF):  SSRF flaws occur when a web app fetches a remote resource without validating the user-supplied URL. An SSRF flaw can allow an attacker to force the app to send a request to an unexpected destination, even when there is protection by a firewall, VPN, or another type of access control list (ACL). SSRF is becoming more severe due to an increase in the usage of cloud services, including the complexity of architectures.

Software development life cycle (SDLC)

The Software Development Lifecycle, or SDLC, is a systematic model that consists of several stages for high-quality software design, development, and testing that developers follow. These stages cover the entire life cycle of software from its inception to completion. It’s essential to track these stages while adopting a modern secure software framework as a guideline. An SSDLC, which is Secure SDLC can help developers adhere to secure code practices in every development stage, from planning to the final stage of operations and maintenance. Following the SSDLC also allows developers to mitigate vulnerabilities found in the software that can easily be overlooked at any stage, thus preventing the release of an insecure product.

7 stages of the SDLC:

1. Planning: The first stage is the planning stage when a team begins to plan a project. At a startup, a team starts figuring out what type of software they want to build and comes up with solutions. They create an outline regarding how they will meet their goals. In addition, determining the project’s cost, how they will raise funding, if they are missing any resources, and most importantly, the schedule and time it will take to complete the project.
2. Systems Analysis & Requirements: The second stage is when a startup can begin to work on a problem or evaluate a need for changes. Teams can determine the project’s functional requirements and research or analyze the end users’ needs. Tools aiding startups in this phase are Computer Aided Systems/Software Engineering (CSA), requirements gathering, and structured analysis.
3. Design and Prototyping: The third stage involves the specifications, features, and operations needed to meet the functional requirements of a proposed system. Developers can outline the details of an app, such as its user and system interfaces, network requirements, and databases. An SRS document gets drafted into a more logical structure and used as a guideline for the programming language of choice. A prototype is built, tested, and reworked as necessary until the desired outcome gets achieved. Prototyping makes the development process faster and easier for system analysts.
4. Development: The fourth stage is when the actual work of development occurs, and the start of production begins. A developer or IT staff, such as a network engineer and/or database developer, begins to do the core work of the project. This stage may include a flow chart to ensure the process remains organized. Focusing on training the development team can be a huge benefit during this phase.
5. Testing: The fifth stage involves systems integration and testing. Software or product testing begins, usually done by a Quality Assurance (QA) professional. Testing may repeat multiple times to check for errors, bugs, and operability issues. This is a good stage to incorporate security testing such as penetration testing or source code scanning.
6. Implementation and Integration: The sixth stage is when most software code gets written. It involves implementing a newly developed system and putting the project into production by moving data and components from the old system and placing them in the new one via a direct cutover.
7. Operations and Maintenance: The seventh and final stage of SDLC involves maintenance and regularly required updates. This final stage is when end-users can fine-tune the system, add new capabilities or meet additional requirements.
   

Modern secure software frameworks

Because insecure code continues to be one of the top critical security risks annually, it is best to start implementing a framework that helps you follow secure code practices. Utilizing modern secure software frameworks can boost a startup’s security posture and provides a guideline for developers and security teams to follow easily. The framework can also help your startup map security controls appropriately and prevent the release of highly insecure software. 

Secure software development frameworks

These are the top four secure software development frameworks that are effective. It is up to your startup to determine which one is appropriate to follow for your project.

1) NIST Secure Software Development Framework (SSDF): The NIST SSDF framework consists of fundamental, sound, and secure development practices based on established documents from organizations such as BSA, OWASP, and SAFECode. SSDF practices must be added to and integrated with each SDLC implementation.

SSDF practices

Per the NIST website, SSDF practices are organized into four groups and defined as the following:

1. Prepare the Organization (PO): Ensure that the organization’s people, processes, and technology perform secure software development at the organization level or individual development groups and projects.
2. Protect the Software (PS): Protect all software components from tampering and unauthorized access.
3. Produce Well-Secured Software (PW): Produce well-secured software with minimal security vulnerabilities in its releases.
4. Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.

Each practice is defined with the following elements:

• Practice: The practice’s name and unique identifier, followed by a brief explanation of what the practice is and why it is beneficial.
• Task: An action that may be needed to perform a specific practice.
• Notional Implementation Example: A notional example of types of tools, processes, or other methods that help implement a task. 
• Reference: A pointer to an established secure development practice document and its mappings to a particular task.

See Table 1 figure below for an example.

2) OWASP Security Knowledge Framework (SKF): The OWASP SKF is a fully open-source web application that uses the OWASP Application Security Verification Standard (ASVS) to explain secure coding principles in various programming languages. Its goal is to help developers or anyone learn and integrate security by design for their software development and build applications that are secure by design. It does this via manageable software development projects with checklists such as the OWASP-ASVS/OWASP-MASVS. As a bonus, it includes labs to practice security verification via SKF-labs or OWASP Juice-shop. OWASP SKF continues to be updated, and its GitHub repository is here.

OWASP secure coding checklist

Software security aims to maintain confidentiality, integrity, and availability of information, also known as CIA. Accomplishing this is possible via implementing security controls that help mitigate vulnerabilities. A Secure Coding Practices checklist is an efficient method of eliminating software vulnerabilities as much as possible. 

The OWASP secure coding checklist:

• Input Validation
• Output Encoding
• Authentication & Password Management
• Session Management
• Access Control
• Cryptographic Practices
• Error Handling & Logging
• Data Protection
• Communication Security
• System Configuration
• Database Security
• File Management
• Memory Management

OWASP ASVS

The OWASP Application Security Verification Standard (ASVS) is a document that consists of the following chapters (i.e., V1, V2, V3) that cover detailed instructions on security requirements. Each requirement has an identifier in the format <chapter>.<section>.<requirement> where each element is a number e.g., 1.11.3. For the sake of keeping it brief, I will carefully detail the entire 14 chapters only.

The 14 OWASP ASVS chapters:

• V1 Architecture, Design, and Threat Modeling: Covers primary aspects of sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. Emphasizes the criticality to “shift left,” beginning with developers enabling secure coding checklists, mentoring and training, coding, and testing, building, deployment, configuration, operations, and independent testing.
• V2 Authentication: The NIST 800-63B is the gold standard for authentication and covers passwords and two-factor authorization. Refer to our article on password management & authentication for more details on it
• V3 Session Management: Ensures that the application in focus has the following session management features: 1) Sessions are unique and cannot be shared or guessed 2) Session timeout occurs after an adequate period of inactivity, and the session becomes invalid.
• V4 Access Control: This chapter sets up guidelines that ensure an application follows specific access control requirements (e.g., only those with required credentials can access particular resources).
• V5 Validation, Sanitization, and Encoding: Covers standards that prevent injection attacks by setting up a secure pipeline for input validation, filtering, and output encoding. 
• V6 Stored Cryptography: Emphasizes that an application’s error handling must be robust and cryptographic modules are fail-safe, secure access to cryptographic keys is maintained, and a random number generation is used to meet cryptographic requirements.
• V7 Error Handling and Logging: Focuses on proper logging and error handling.
• V8 Data Protection: Confidentiality, integrity, and availability (CIA) must be maintained during storage and transit, data must be protected and backed up, and data must always remain available to authorized end-users.
• V9 Communication: Guidance is provided in this chapter for developers on how to use strong encryption or transport layer security at all times, and advises to use the most novel configuration algorithms and disable all insecure ciphers and algorithms to maintain the security of app data.
• V10 Malicious Code: Covers the high level requirements that code must satisfy. Malicious activity in code must be handled securely and properly not to affect the rest of the organization, time-based attacks and time bombs should not be present, code should not “phone home” to malicious or unauthorized destinations, and backdoors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker must not be present. 
• V11 Business Logic: Details how to follow business logic requirements so malicious actors cannot bypass them. 
• V12 Files and Resources: Explains how data from untrusted sources are handled in a compliant manner, meeting regulations, and that data from third-party and untrusted sources must be stored out of the webroot and given limited permissions.
• V13 API and Web Service: Provides recommendations for APIs in an application: APIs must have adequate authorization, essential session management parameters, and authentication to access all web services. It also includes proper input validation and security controls. 
• V14 Configuration: Several configuration requirements are covered in this last chapter. It ensures a verified application has a secure, repeatable, and automatable build environment. The application must have a hardened third-party library and a suitable configuration and dependency management system to filter outdated or insecure components. 

3) BSA Framework for Secure Software: The BSA Framework for Secure Software is organized into six columns: Functions, Categories, Subcategories, Diagnostic Statements, Implementation, Notes, and Informative References. It is intended to establish a flexible, adaptable, outcome-focused, risk-based, cost-effective, and repeatable approach to software security. It identifies best practices relating to organizational processes and product capabilities across the entire software development lifecycle (SDLC).

Functions

Functions organize fundamental software security activities at their highest level consistent with the SDLC.

Framework functions:

• Secure Development: Addresses security in the phase of software development when a software project is conceived, initiated, developed, and brought to market
• Secure Capabilities: Identifies key security characteristics recommended for a software product
• Secure Lifecycle: This Function addresses considerations for maintaining security in a software product from its inception through the end of its life.

Categories

Categories divide a Function into distinct considerations and disciplines that are relevant to the Function. Categories can be combined with other Categories such as “Vulnerability Management” or “Vulnerability Notification and Patching.”

Subcategories

These divide a Category into distinct, unitary concepts that express identified software security best practices.

Diagnostic Statements

Diagnostic statements identify specific, verifiable outcomes. They provide a set of results that help support the achievement of each Category’s outcomes.

Implementation Notes

Provides additional information, where necessary, such as examples of how organizations may achieve security outcomes described in the Diagnostic Statements, interpretations of how Diagnostic Statements may apply in different development environments, and guidance on aligning implementation with risk.

Informative References

These are additional resources that identify and describe best practices, guidelines, or further information for implementing an associated Diagnostic Statement. 

The BSA Software Security Fundamentals Framework is based on five fundamental principles:

1. Risk-based
2. Outcome-focused
3. Flexible
4. Adaptable
5. Aligned with Internationally Recognized Standards

4) SAFECode: The core principle behind the SAFECode framework is a software assurance assessment that primarily focuses on the secure software development process and its application to the product being assessed while considering the context of a product’s intended operations environment. No single practice, tool, or checklist acts as a silver bullet and guarantees better software assurance.

Guiding principles for Software Security Assessment 

1. Software assurance is not achieved by a single practice, tool, or checklist; instead, it results from a comprehensive, secure software engineering process. 
2. A tiered approach for assessing the security of acquired software based on the maturity of the technology provider developing the software is necessary. 
3. The current problems many customers and suppliers face require an immediate solution in the short term and comprehensive, widely accepted international standards in the medium or long term. 
4. Customers may require evidence to support a supplier’s claims. 
5. Customers need insight into corporate and product-level assurance processes to support their risk management needs.

Figure 1: Overview of SAFECode Assessment Framework

Three-Tier Assessment Approach

Suppose the supplier lacks a mature software security process or is unwilling to provide information on that process. In that case, testing tools or other product testing techniques to detect security flaws in product code can be the basis of an assessment. This assessment is the Three-Tier Assessment Approach, which is effective for detecting security flaws and can give a customer confidence in a product’s security. (See Three-Tier Assessment in Figure 1.)

Two-Tier Assessment

If an industry-standard does not apply, the assessment should be based on current and well-understood industry best practices (Tier Two Assessment in Figure 1).

Tier-One Assessment

Let’s say a customer determines that its risk management requirements call for a high degree of confidence in assurance for a given software application and a supplier has a mature, secure software development process; it can provide insight into its software security methodology. Then, a process-based assessment approach is recommended. If an international standard is available and applicable to a supplier, that standard should drive the scope of the assessment (Tier One Assessment in Figure 1).

Conclusion

A startup must follow a modern secure software framework to ensure developers follow guidelines for best secure coding practices during the software development lifecycle (SDLC). Indeed, no single framework or checklist can act as a silver bullet that guarantees maximum security at all levels. Still, it can significantly reduce vulnerabilities and eliminate careless mistakes such as releasing a product or app with insecure code without reviewing them. A startup can avoid a financial disaster or data breach by preventing the top critical security risks that continue to affect software. With a proper software security approach, startups can boost their security posture and have healthy business continuity.

Sources:

1. https://dzone.com/articles/low-code-and-no-code-the-security-challenge
2. https://www.zdnet.com/article/google-half-of-zero-day-exploits-linked-to-poor-software-fixes/
3. https://www.reversinglabs.com/newsroom/press-releases/survey-software-supply-chain-risk-software-tampering
4. https://owasp.org/www-project-top-ten/
5. https://thenewstack.io/armo-misconfiguration-is-number-1-kubernetes-security-risk/
6. https://www.techtarget.com/whatis/feature/SolarWinds-hack-explained-Everything-you-need-to-know
7. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
8. https://owasp.org/www-pdf-archive/OWASP_SCP_Quick_Reference_Guide_v2.pdf