> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/resources/policies-and-security/corporate-policies-and-security-compliance/product-level-certifications/backup-and-archive/flosum-backup-and-archive-security-and-compliance-statement/software-development-security-guidelines.md). # Software Development Security Guidelines Creating and enforcing security policies and procedures is essential to improve security and mitigate risks within an organization. These policies serve as guidelines for our employees and to follow, ensuring that proper security measures are in place to protect sensitive information, systems, and assets. Flosum employees are trained routinely on security awareness.\ \ Flosum is responsible for developing, maintaining, and participating in a Systems Development Life Cycle (SDLC) for our development projects. All employees engaged in systems or software development activities must follow the Flosum SDLC. Flosum certification and audit reports are available upon request.\ \ All software developed for production systems must be developed according to the SDLC standards. At a minimum, our software development plan addresses the areas of preliminary analysis or feasibility study, risk identification and mitigation, systems analysis, general design, detail design, development, quality assurance and acceptance testing, implementation, and post-implementation maintenance and review.\ \ This methodology ensures that the software will be adequately documented and tested before it is used in conjunction with critical and/or sensitive information. All development work shall exhibit a separation between production, development, and test environments, and at a minimum have at least a defined separation between the development/test and production environments unless an exception is made. These separation distinctions allow better management and security for the production systems, while allowing greater flexibility in the pre-production environments.\ \ Where these separation distinctions in environments have been established, development, and QA/test staff shall not be permitted access to production systems unless absolutely required by their respective job duties/descriptions. All application/program access paths utilized in development or testing, other than the formal user access paths, must be deleted or disabled before software is moved into production. All releases must be tested on a staging environment which mirrors production infrastructure before being released to the live production environment. In the testing phase, various types of tests are conducted, such as penetration testing, vulnerability application scanning, application code scanning, manual review, and functional security testing. These tests help identify any security weaknesses in the application, which can be addressed before the application is deployed. Static code analyzers (Fortify) can also be used to check for vulnerabilities. \ \ Documentation must be kept and updated during all phases of development from the initiation phase through implementation and ongoing maintenance phases. Additionally, security considerations are to be noted and addressed through all phases. All software and web applications that create, manage, use, or transmit information, must be developed and maintained solely by Flosum software engineers. *** ### FedRAMP and GovCloud Customers With the customer-hosted version of Flosum Backup & Archive, Gov Cloud customers can install Backup & Archive on their own private cloud (Dod/DHA AWS, Google Cloud, Azure) or on their own physical servers (virtual linux servers). Therefore, there is no need for Flosum Backup & Archive to be FedRAMP certified. Our solution is built to run in the Government AWS environment and we currently have multiple government customers using Flosum Backup & Archive on their private cloud. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.flosum.com/resources/policies-and-security/corporate-policies-and-security-compliance/product-level-certifications/backup-and-archive/flosum-backup-and-archive-security-and-compliance-statement/software-development-security-guidelines.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.