To tackle the security of code developed in-house, OWASP offers an extensive collection of Cheatsheets demonstrating how to implement features securely. Moreover, the Security Knowledge Framework[1] offers an extensive library of code patterns spanning several programming languages. These patterns can be used to not only jumpstart the development process, but also do so securely. [...] The Requirements gathering process tries to answer the question: "What is the system going to do?" At this stage, the SAMM project offers 3 distinct maturity levels covering both in-house software development and third party supplier security. Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process. These general security considerations can be audited by using a subsection of the ASVS controls in section V1 as a questionnaire. This process attempts to ensure that every feature has concrete security considerations. In case of internal development and if the organization maps Features to Epics, the Security Knowledge Framework can be used to facilitate this process by leveraging its questionnaire function, shown below. Source: OWASP Project Integration

Risk: Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.

Bear in mind that utilizing frameworks is a recommended approach; however, they can develop known security weaknesses over time. Diligent and regular patching is crucial.

By concatenating strings from user input to build SQL queries, an attacker can manipulate the query to do other unintentional SQL commands as well. This is called SQL injection but the principle applies to NoSql, and anywhere that your code is building commands that will be executed. Pay attention to these two lines of code. They seem similar, but behave very differently.

• `sql.execute("SELECT * FROM table WHERE ID = " + id);`
• `sql.execute("SELECT * FROM table WHERE ID = ?", id);` The second line is parameterized. The same principle applies to other types, such as command line execution, etc.

Risk: Systems vulnerable to injections may lead to data breaches, loss of data, unauthorized alteration of data, or complete database compromise or downtime. This applies to SQL, NoSql, LDAP, XPath, email headers OS commands, etc.

To tackle the security of code developed in-house, OWASP offers an extensive collection of Cheatsheets demonstrating how to implement features securely. Moreover, the Security Knowledge Framework[1] offers an extensive library of code patterns spanning several programming languages. These patterns can be used to not only jump-start the development process, but also do so securely. [...] The Requirements gathering process tries to answer the question: "What is the system going to do?" At this stage, the SAMM project offers 3 distinct maturity levels covering both in-house software development and third party supplier security. Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process. These general security considerations can be audited by using a subsection of the ASVS controls in section V1 as a questionnaire. This process attempts to ensure that every feature has concrete security considerations. In case of internal development and if the organization maps Features to Epics, the Security Knowledge Framework can be used to facilitate this process by leveraging its questionnaire function, shown below. Source: OWASP Project Integration

Containers are running as non-root. This can be enforced in the image itself or during runtime parameters (e.g. podman run --user [...]).

Risk: There are various reasons to run a container as non-root. Samples are listed:

• Root privileges significantly increase the chance of breaking container isolation
• Root access can be leveraged to exploit kernel vulnerabilities
• Compromised root containers provide attackers with maximum privileges inside the container
• Greater potential for escaping container boundaries to the host system

Root containers can potentially:

• Mount sensitive host filesystems
• Access critical device files
• Modify host network settings
• Interact with host system processes
• Override security controls

Root privileges may allow containers to:

• Bypass resource quotas and limits
• Modify control group (cgroup) settings
• Interfere with other containers' resources
• Circumvent memory and CPU restrictions Security Boundary Weakening
• Violates the principle of least privilege
• Provides unnecessary elevated permissions
• Expands the potential attack surface
• Increases the impact of a successful compromise

Following frameworks like the * OWASP Application Security Verification Standard Level 2 * OWASP Mobile Application Security Verification Standard Level 2 Implement 75% of the recommendations.

Risk: Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.

Implement and enforce security headers across all applications and services Implementation Methods:

1. Reverse Proxy/Load Balancer: Configure at nginx/Apache level
2. Web Application: Implement in the application middleware
3. Service Mesh: Configure at the ingress controller level
4. Standard Docker Image: Use secure base images with preset headers

Remove or Secure:

• Server header: Hide server version information
• X-Powered-By: Remove technology stack information

Risk: Missing or misconfigured security headers can lead to various security vulnerabilities, e.g.:

• Cross-Site Scripting (XSS) due to missing Content Security Policy
• Clickjacking attacks due to missing X-Frame-Options
• Information disclosure through Server header exposure
• SSL/TLS downgrade attacks due to missing HSTS
• Cross-site scripting and injection due to missing security headers

Following frameworks like the * OWASP Application Security Verification Standard Level 2 * OWASP Mobile Application Security Verification Standard Level 2 Implement 95%-100% of the recommendations.

Risk: Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.

Following frameworks like the * OWASP Application Security Verification Standard Level 3 * OWASP Mobile Application Security Verification Standard Implement 95%-100% of the recommendations.

Risk: Using an insecure application might lead to a compromised application. This might lead to total data theft or data modification.