wiki:policies:dev
Differences
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/06/24 23:08] 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 ===== | ||
| - | All application data are stored and processed inside the VPC. Data leaving the VPC are either encrypted to the authenticated & authorized client, or, in the case of external providers contain minimal & nonsensitive information (e.g. DOIs for unpaywall, search strings for PubMed). Within the VPC, communications between the database and all services are encrypted. | + | ==== General ==== |
| - | Nested Knowledge does not manage user passwords or other authorization | + | All application data are stored and processed inside the VPC. Data leaving the VPC are either encrypted to the authenticated & authorized client, or, in the case of external providers contain minimal & nonsensitive information (e.g. DOIs for unpaywall, search strings for PubMed). HTTP traffic is served over HTTPS (redirect required); email traffic (through AWS SES) is encrypted from application to sender (TSL), and sender to receiver (TSL). Within the VPC, communications between the database and all services are encrypted. |
| + | |||
| + | ==== Authentication ==== | ||
| + | |||
| + | Nested Knowledge does not manage user passwords or authentication | ||
| ====== Software Applications on NK-Owned Devices ====== | ====== Software Applications on NK-Owned Devices ====== | ||
| 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 95: | 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 103: | 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 110: | 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/ | ||
| [[: | [[: | ||
wiki/policies/dev.1656112084.txt.gz · Last modified: 2022/06/24 23:08 by kholub
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
