> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/corporate/corporate/end-user-product/product-security.md).

# Product Security

**1. Purpose** This policy outlines MFC Safe's approach to securing our digital products throughout their lifecycle. It ensures that our platform and services are designed, developed, tested, and maintained with a strong focus on preventing, detecting, and responding to security vulnerabilities.

**2. Scope** Applies to all software and hardware components of the MFC Safe platform ("Didge"), including APIs, mobile and web applications, integrations, firmware, and third-party libraries.

**3. Secure Software Development Lifecycle (SSDLC)**

* **Security Requirements:** Security requirements are defined for every feature at the planning stage.
* **Threat Modeling:** Conducted during design to identify potential risks.
* **Secure Coding Practices:** All development follows OWASP and industry best practices.
* **Code Reviews:** All code changes undergo peer review with a focus on security.
* **Automated Security Testing:** Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools are employed in CI/CD pipelines.

**4. Vulnerability Management**

* **Regular Scanning:** All applications and components are scanned for vulnerabilities using tools such as Dependabot, SonarQube, or similar.
* **Patch Management:** High and critical vulnerabilities must be patched within 7 days; medium within 30 days.
* **Disclosure Program:** Security researchers and users can report vulnerabilities via a dedicated email or disclosure form.

**5. Penetration Testing**

* **Internal Testing:** Conducted quarterly by MFC Safe's security team.
* **Third-Party Testing:** Annual independent security assessments, including black-box and white-box testing.
* **Remediation Plan:** Findings are documented, prioritized, and remediated as per severity.

**6. Roles & Responsibilities**

* **Security Lead:** Oversees implementation of this policy.
* **Developers:** Required to complete secure coding training annually.
* **DevOps Team:** Ensures security tools are integrated in the CI/CD pipeline.

**7. Compliance & Reporting**

* Logs of scans, test results, and remediation actions are maintained.
* Results are included in internal audit reviews and may be shared with enterprise clients upon request.

**8. Policy Review** This policy is reviewed annually or after any major security incident.

***

**Approved by:** CTO, MFC Safe

**Effective Date:** 02 April 2025

**Review Date:** \[One year from effective date]

**Document ID:** POL-SEC-005


---

# 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.didge.io/home/corporate/corporate/end-user-product/product-security.md?ask=<question>&goal=<user_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.