This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
wiki:policies:dev [2022/08/31 16:43] kholub |
wiki:policies:dev [2024/01/25 23:02] (current) katcow |
||
---|---|---|---|
Line 33: | Line 33: | ||
=== Supplier Adherence to SDLC === | === Supplier Adherence to SDLC === | ||
- | Nested Knowledge employees develop all application code. External platforms (e.g. AWS) may provide architecture, | + | Nested Knowledge employees develop all application code. External platforms (e.g. AWS) may provide architecture, |
* A review of technical documentation | * A review of technical documentation | ||
Line 43: | Line 43: | ||
* Automate scanning for existing vulnerabilites using NPM vulnerability scanning, the pypi Safety DB, and GitHub vulnerability monitoring. | * Automate scanning for existing vulnerabilites using NPM vulnerability scanning, the pypi Safety DB, and GitHub vulnerability monitoring. | ||
* Does the supplier actively maintain the solution? | * Does the supplier actively maintain the solution? | ||
- | * Does the supplier follow a standardized release | + | * Does the supplier follow a standardized release |
* Are there reports of major version changes that weren' | * Are there reports of major version changes that weren' | ||
* Does the solution include a public issue tracker? | * Does the solution include a public issue tracker? | ||
* Are issues (bugs & security vulnerabilities) addressed quickly? | * Are issues (bugs & security vulnerabilities) addressed quickly? | ||
+ | * Does the solution have a policy and/or history of disclosing vulnerabilities and breaches? | ||
* When available, code & version history review. | * When available, code & version history review. | ||
* Do all commits to the repository leave it in deployable condition? | * Do all commits to the repository leave it in deployable condition? | ||
Line 75: | Line 76: | ||
====== System Design and Architecture ====== | ====== System Design and Architecture ====== | ||
- | The Nested Knowledge client application is served by an application server and hydrated by an API server; both of these servers run behind a load balancer. The API server communicates with the Search and ML backend services as well as the database. Certain functions of backend services communicate with external (public) APIs. The frontend servers, services, and database all run in a Vitrual | + | The Nested Knowledge client application is served by an application server and hydrated by an API server; both of these servers run behind a load balancer. The API server communicates with the Search and ML backend services as well as the database. Certain functions of backend services communicate with external (public) APIs. The frontend servers, services, and database all run in a Virtual |
- | {{ : | + | {{: |
===== Security Requirements ===== | ===== Security Requirements ===== | ||
Line 92: | Line 93: | ||
Our [[https:// | Our [[https:// | ||
- | |||
- | At this time, Nested Knowledge does not issue personal computers or mobile devices to employees or contractors. | ||
====== Vulnerability and Patch Management ====== | ====== Vulnerability and Patch Management ====== | ||
Line 99: | Line 98: | ||
Nested Knowledge uses automated scanning to identify potential vulnerabilities in our operating environment and software dependencies. The risk of a vulnerability is assessed using the [[https:// | Nested Knowledge uses automated scanning to identify potential vulnerabilities in our operating environment and software dependencies. The risk of a vulnerability is assessed using the [[https:// | ||
- | Our cloud services provider (AWS) provides automated vulnerability reports on operating systems & databases running the application. Alerts derived from these reports are addressed by release engineers: | + | Our cloud services provider (AWS) provides automated vulnerability reports on operating systems & databases running the application. Application vulnerability scanning is performed by SecurityScorecard on an ongoing basis. Alerts derived from these reports are addressed by release engineers: |
- | * The applicability & risk of the vulnerability is verified. If a vulnerability is deemed nonapplicable or low severity, it is added to our issue tracker. If applicable or medium or high severity, the vulnerability is assigned | + | * The applicability & risk of the vulnerability is verified |
* The viability of the recommended patch is assessed. | * The viability of the recommended patch is assessed. | ||
* Bug fix / minor version patches may be applied with minimal testing. | * Bug fix / minor version patches may be applied with minimal testing. | ||
Line 107: | Line 106: | ||
* The patch is applied during the next scheduled release window. If a vulnerability is deemed high severity, it triggers an immediate release upon review completion. | * The patch is applied during the next scheduled release window. If a vulnerability is deemed high severity, it triggers an immediate release upon review completion. | ||
- | Our dependency management tools (NPM & pip) provide automated vulnerability | + | Our dependency management tools (NPM, pip, apt-get) provide automated vulnerability |
* The applicability & risk of the vulnerability is verified. If a vulnerability is deemed nonapplicable or low severity, it is added to our issue tracker. If applicable or medium or high severity, the vulnerability is assigned to an engineer immediately. | * The applicability & risk of the vulnerability is verified. If a vulnerability is deemed nonapplicable or low severity, it is added to our issue tracker. If applicable or medium or high severity, the vulnerability is assigned to an engineer immediately. | ||
Line 114: | Line 113: | ||
* Contribute an upstream patch, for open source dependencies. | * Contribute an upstream patch, for open source dependencies. | ||
* Mitigate code paths triggering the vulnerability and begin researching alternative dependencies. | * Mitigate code paths triggering the vulnerability and begin researching alternative dependencies. | ||
+ | * Replace or remove the dependency, with application code changes | ||
* The dependency and/or code change is deployed during the next scheduled release window. If a vulnerability is deemed high severity, it triggers an immediate release upon review completion. | * The dependency and/or code change is deployed during the next scheduled release window. If a vulnerability is deemed high severity, it triggers an immediate release upon review completion. | ||
=== Revision History === | === Revision History === | ||
- | This policy will be reviewed | + | This policy will be updated at least on an annual basis or when a signficant change occurs. |
^Author^Date of Revision/ | ^Author^Date of Revision/ | ||
- | |K. Cowie|12/17/2021|Minor Revisions to Secure Development Policy| | + | |K. Cowie|01/24/2023|Reviewed| |
- | |K. Holub|06/24/2022|Updated secure development environment standard| | + | |K. Holub|03/30/2023|Updating vulnerability scanning to include SecurityScorecard| |
|K. Kallmes|11/ | |K. Kallmes|11/ | ||
+ | |P. Olaniran|9/ | ||
[[: | [[: | ||