-
Practices
- Static Application Security Testing (SAST)
- Threat Modeling
- Secure Code Review
- Dependency Scanning
- Code Signing
- Access Control
- Security Audits
- Secure Programming Language Adoption
-
Tools
- SonarQube
- Checkmarx
- OWASP Threat Dragon
- Dependabot
- Snyk
- GPG
- SSH Keys
- Terraform
- Ansible
-
Concepts
- CI/CD Pipeline
- Design Phase
- Peer Review
- Third-Party Component Management
- Vendor Assessment
- Audit Logging
- Role-Based Access Control (RBAC)
- Security Assessment
- Memory Safety
-
Metrics
- Vulnerabilities Detected
- Vulnerabilities Resolved
- Codebase Coverage
- Frequency of Threat Modeling
- Security Incidents
- Time to Patch
- Unauthorized Access Attempts
- Access Control Violations
- Security Audit Feedback
| Why | How (Process) | What (Resources) | Metrics |
|---|---|---|---|
| To identify and mitigate security vulnerabilities early in the development process. | - Implement Static Application Security Testing (SAST): Integrate SAST tools into the CI/CD pipeline to automatically scan code for vulnerabilities during development. - Conduct Threat Modeling: Perform threat modeling sessions during the design phase to anticipate potential security threats and design countermeasures. -- Perform Secure Code Reviews: Establish a process for regular peer reviews focusing on security aspects of the code. |
- SAST tools (e.g., SonarQube, Checkmarx). - Threat modeling frameworks (e.g., OWASP Threat Dragon). - Secure coding guidelines and checklists. |
Internal Metrics: - Number of vulnerabilities detected and resolved during development. - Percentage of codebase covered by SAST scans. - Frequency and effectiveness of threat modeling sessions. External Metrics: - Reduction in security incidents post-deployment. - Compliance with industry security standards and regulations. |
| To ensure secure management of third-party components and dependencies. | - Implement Dependency Scanning: Use automated tools to scan for vulnerabilities in third-party libraries and dependencies. - Maintain an Updated Inventory: Keep an up-to-date inventory of all third-party components used in the project. Establish Vendor Assessment Procedures: Evaluate the security practices of third-party vendors before integration. |
- Dependency scanning tools (e.g., Dependabot, Snyk). - Inventory management systems. - Vendor assessment frameworks and questionnaires. |
Internal Metrics: - Number of vulnerabilities identified in dependencies. - Time taken to update or patch vulnerable components. - Percentage of third-party components with known vulnerabilities. External Metrics: - Compliance with supply chain security requirements. - Feedback from security audits regarding third-party component management. |
| To detect and prevent malicious commits in the codebase. | - Implement Multi-Factor Authentication (MFA): Require MFA for all code repository accesses to ensure that only authorized personnel can make changes. - Enforce Code Signing: Mandate that all commits are signed with verified cryptographic keys to ensure authenticity. - Conduct Regular Audits: Perform periodic audits of commit histories to identify and investigate suspicious activities. |
- MFA tools (e.g., hardware tokens, authenticator apps). - GPG or SSH keys for commit signing. - Audit logging systems integrated with version control platforms. |
Internal Metrics: - Number of unsigned or improperly signed commits detected. - Frequency of unauthorized access attempts to repositories. - Time taken to detect and respond to suspicious commit activities. External Metrics: - Reduction in security breaches due to compromised code. - Increased stakeholder confidence in code integrity. |
| To secure the build and deployment infrastructure against potential threats. | - Implement Infrastructure as Code (IaC): Define and manage infrastructure using code to ensure consistency and enable automated security checks. - Enforce Access Controls: Restrict access to build and deployment systems based on the principle of least privilege. - Conduct Regular Security Assessments: Perform vulnerability assessments and penetration testing on the build and deployment pipelines. |
- IaC tools (e.g., Terraform, Ansible). - Role-based access control (RBAC) systems. - Security assessment tools and services. |
- Internal Metrics: - Number of vulnerabilities identified and remediated in the build pipeline. - Frequency of access control policy violations. - Time taken to deploy security patches to infrastructure. External Metrics: - Compliance with deployment security standards. - Reduction in incidents related to deployment infrastructure. |
| To reduce entire classes of vulnerabilities at scale. | - Adopt Safer Programming Languages: Transition to programming languages that inherently reduce certain types of vulnerabilities (e.g., Rust for memory safety). - Mandate Secure Coding Frameworks: Require the use of frameworks and libraries that enforce security best practices. - Provide Developer Training: Offer regular training sessions focused on secure coding practices and common vulnerability mitigation. |
- Resources for learning and adopting safer programming languages. - Secure coding frameworks and libraries. - Training materials and programs on secure coding. |
Internal Metrics: - Reduction in the number of specific vulnerability types (e.g., buffer overflows) in the codebase. - Percentage of developers who have completed security training. - Adoption rate of secure coding frameworks. External Metrics: - Decrease in security incidents reported by end-users. - Improved compliance with security certifications and standards. |
| To foster a company culture conducive to securing the software supply chain. | - Establish Security Champions: Designate team members as security advocates to promote best practices within development teams. - Incentivize Secure Development: Implement reward systems for teams that consistently adhere to security protocols. - Encourage Open Communication: Create channels for employees to report security concerns without fear of retribution. |
- Security training programs and workshops. - Communication platforms for reporting and discussing security issues. - Recognition and reward systems for secure development practices. |
Internal Metrics: - Employee participation rates in security programs. - Number of security issues reported internally. - Frequency of security-related discussions in team meetings. External Metrics: - Enhanced reputation for security among clients and partners. - Reduction in security incidents originating from internal practices. |
@misc{nordlayer_security_practices,
author = {NordLayer},
title = {Software Development Security Best Practices},
year = {2023},
howpublished = {url{https://nordlayer.com/blog/software-development-security-best-practices/}},
note = {Accessed: 2025-01-11} }
@article{arxiv_secure_supply_chain,
author = {Anonymous},
title = {S3C2 Summit 2023-11: Industry Secure Supply Chain Summit},
year = {2024},
month = {August},
journal = {arXiv preprint arXiv:2408.16529},
url = {https://arxiv.org/pdf/2408.16529},
note = {Accessed: 2025-01-11} }
- Size of the Code Change – Keep pull requests small and focused to simplify review and reduce the chance of missing issues.
- Documentation – Include clear descriptions of what changed and why. This helps reviewers follow the logic and spot flaws.
- Testing – Ensure unit and security tests are in place and passing. Test coverage builds trust in the change.
- Formatting and Linting – Use automated tools to enforce consistent style and catch basic issues early.
- Static Analysis – Run static analysis and security scans before review to catch common problems automatically.
- Shift Left – Integrate security early—during development—not just before deployment.
- Input Validation Issues – always validate and sanitize user inputs to prevent injection and malformed data errors.
- Authentication and Authorization Flaws – enforce strong authentication and limit access based on roles or permissions.
- Data Encryption and Secure Communication – use HTTPS and encrypt sensitive data both in transit and at rest.
- Exception Handling and Logging – avoid exposing stack traces or secrets in errors or logs. Secure your logs.
- Dependency Management – regularly update third-party libraries and remove unused or risky packages.
- API and Integration Points – validate all API input/output, secure API keys, and limit API exposure.
- CSRF Protections – protect state-changing actions with CSRF tokens and confirm user intent.
- Server-Side Code Execution – avoid executing user-controlled input on the server without strict validation.
- Business Logic Errors – review logic flows and edge cases to avoid exploitable behavior.
- Code Quality and Best Practices – write clean, modular, and well-documented code to reduce hidden risks.
- Track security bugs over time to improve processes and prioritize fixes.
- Balancing Security and Functionality: Security should support, not block, functionality. Work with teams to make protection practical.
- What is the primary goal of integrating Static Application Security Testing (SAST) into the CI/CD pipeline?
- Name two SAST tools mentioned in the document and describe their general use.
- At what stage of the software development lifecycle should threat modeling ideally be performed? Why?
- What is the purpose of conducting secure code reviews during development?
- What types of metrics are used to evaluate the effectiveness of SAST?
- What internal metrics are suggested for assessing secure coding practices?