Secure Software Development Lifecycle (SDLC)

Design is the foundation of your organization software development. We try to make Software and API design easy by using powerful tools for developers, architects, and product owners.

your organization embraces the "spec-first development" principle, which primarily helps us write documentation for teams at large, not just for engineering. Defining the specification before implementation also helps your organization teams create better APIs by discussing and approving the final version of the interaction interface.

This design process shall include:

• business and legal aspects (data protection, data handling, business impact, costs)
• product technical architecture design (features, components, technologies)
• software security architecture design (access, authorization, data security, open-source software security)
• threat modeling - analysis to identify risks and attack vectors, and to specify the security controls that must be folded into the design that will be implemented

All your organization products are using automation for generating Documentation, Guides, and API References. This is accomplished by adding annotations to classes, functions, methods, variables, and any other software primitive that needs it. Narratives are included around continuous integration and continuous delivery so that the path your organization's code takes from development to staging to production is clear. This verbose documentation helps current and future team members, users, customers, and partners align with the company's established way of doing development, and also makes an auditor's job easier. your organization uses:

• OpenAPI to generate API References
• Swagger as Interface Description Language for describing RESTful APIs expressed using JSON.

Example of Golang code annotations for automatic API Specs generation:

// @title Business API
// @version 3.0
// @description This is a sample Gin server
// @termsOfService https://companyDomain.tld/terms/

// @contact.name API Support
// @contact.url https://companyDomain.tld/support
// @contact.email [email protected]

// @license.name Apache 2.0
// @license.url http://www.apache.org/licenses/LICENSE-2.0.html

// @host api.companyDomain.tld
// @BasePath /v2

package docs

import "gitlab.com/cyscale/swagger-automation/api"

// swagger:route POST /foobar foobar-tag idOfFoobarEndpoint
// Foobar does some amazing stuff.
// responses:
//   200: foobarResponse

// This text will appear as description of your response body.
// swagger:response foobarResponse
type foobarResponseWrapper struct {
 // in:body
 Body api.FooBarResponse
}

your organization uses git integrated with a ticketing solution. This allows your organization to maintain a high standard for the code it produces, but also to provide traceability. These systems are also used for code reviews, code verifications, and code signing.

Security training is provided before access to Source Code Repositories (see Security Training and Awareness Policy).

All development is done following these rules:

• access to Source Code Repositories is done only by authentication with your your organization unique identification;

• authentication can be done by unique identification + password or by using an SSH key pair;

• commits are made in a dedicated branch named with the ticket/issue number and the title of the ticket;

• commit messages must follow the Conventional Commits Open Standard;

• each feature branch must enter the CI phase for Unit Testing and Integration Testing;

• Merge Requests (MR)/Pull Requests (PR) are created using git;

• commits are reviewed by peers, automation tools, and the engineering manager for that project.

• main is the ONLY branch which will be promoted to production:

  • main branch cannot be deleted;
  • commits to the main branch are restricted;
  • Merge Requests (MR)/Pull Requests (PR) can be merged into main only with the approval and after all the builds in the request are successful;
  • new feature/defect/bug author must merge the approved branch into the main branch.

More info about the release and deployment to production can be found in the Software Release Process.

Open-source software is a rapidly growing market because every user has access to the respective programming code, can audit what the code's functionality is, and can edit the code to fit specific requirements. The majority of technologies used at your organization are under the Apache 2.0 license which allows for use, modification, and distribution of the open-source technologies, as long as references are included in the license header.

your organization Security Team is responsible for creating and maintaining an up-to-date software inventory of all open-source software dependencies, as well as scanning for issues and security vulnerabilities. Development Teams are responsible for either selecting a secure OSS or fixing any problems before deployment to production. In the end, any licensing issues discovered in 3rd Party software or libraries must be properly addressed.

Dependency-check, Dependency-track, and Snyk are used at your organization for open source software licensing and vulnerabilities identification.

Open Source Software Inventory

| License | OSS Software | |-------------|-------------------| | Apache 2.0 | Kubernetes | | Apache 2.0 | Docker | | Apache 2.0 | Gitlab | | Apache 2.0 | Jenkins | | Apache 2.0 | OpenVPN | | Apache 2.0 | VS Code | | Apache 2.0 | Elasticsearch | | Apache 2.0 | SonarQube | | Apache 2.0 | Dependency-track | | Apache 2.0 | Dependency-check | | GNU | Go (lang) | | GNU | MariaDB | | GNU | MongoDB | | GNU | Redis | | GPL | Ubuntu 18.04 |

your organization Test Strategy will adhere to the DevOps SDLC methodology. Most of the security testing and validation can be performed using the security-tools container image or by using CI/CD pipeline steps.

Definitions:

• Secrets Detection - API keys, database credentials, and security certificates
• Dependency Scanning
• SAST - Static Application Security Testing or white box testing
• DAST - Dynamic Application Security Testing
• RASP - Run-time Application Self Protection
• IaC - Infrastructure as Code

Based on this methodology, any project will have the following:

| Testing Category | Environment | Responsible(s) | Tool(s) | |-----------------------|-------------|-----------------|---------------------------------------| | Unit | Dev | Developers | Jest, Go | | Code coverage | Dev | Developers | Mocha, SonarQube | | Integration | Dev | Developers | Language-specific | | IaC Scanning | Dev | Developers | Checkov by BridgeCrew | | Secrets Detection | Dev | Developers | GitGuardian | | SAST | QA | CI | SonarQube, Snyk, White Source | | RAST | QA | CI | Sqreen, SonarQube, Snyk | | Application (& DAST) | Dev | Developers | OWASP ZAP, Nikto, Contrast Security | | End-to-End | QA | CI | Selenium, Katalon Studio, Appium | | Performance | Stage | CI | Prometheus, Grafana, ElasticStack | | Vulnerability Scan | Stage | Security | OpenVAS, Nikto, Clair, Anchore | | Penetration Testing | Stage | Security | OWASP ZAP, Zenmap, Kali Linux | | UAT | Prod | QA/PM | - | | Production smoke | Prod | CI | Postman, Fiddler |

your organization engineering and security teams will apply the appropriate combination of tools depending upon the target programming language, architecture, and the execution run-time. These tools are a combination of internally developed, vendor purchased, and open-source tools. As supporters of the OWASP Foundation's initiative, your organization uses many of the security tools listed in OWASP Security Testing Tools and OWASP Vulnerability Scanning Tools webpages.

The SDL describes the "what" of software security. your organization's Security Maturity Model describes the "how well" of software security.

For each SDL activity, the SAMM describes 5 different levels from 0-4. In the end, a radar chart must be created as a statement of how well the new product, software, service, or tool performs under security stress.

1. None
2. Minimal [Initial]
3. Good [Basic]
4. Better [Acceptable]
5. Best [Mature]

The Software Development Life Cycle doesn't end with the deployment to production. Changes must be monitored constantly to ensure proper operation. Bugs and defects discovered in Production must be reported and responded to, which often feeds work back into the process. Bug fixes may not flow through the entire cycle, however, at least an abbreviated process is necessary to ensure that the fix does not introduce other problems (known as a regression), or doesn't affect Protected data in Production environments.

Metrics are captured using monitoring and logging such as Prometheus and Grafana to calculate deltas (before and after deployments).