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 [2021/12/17 17:00] katcow |
wiki:policies:dev [2024/01/25 23:02] (current) katcow |
||
|---|---|---|---|
| Line 11: | Line 11: | ||
| These standards apply to all persons involved in the acquisition, | These standards apply to all persons involved in the acquisition, | ||
| - | ===== III. Policy ===== | + | ===== III. Secure Development |
| === Restrictions on Changes to Software Packages === | === Restrictions on Changes to Software Packages === | ||
| Line 23: | Line 23: | ||
| === Secure Development Environment === | === Secure Development Environment === | ||
| - | Development environments need to be protected against malicious or accidental development and update of code that may create vulnerabilities or compromise confidentiality. | + | Development environments need to be protected against malicious or accidental development and update of code that may create vulnerabilities or compromise confidentiality. |
| + | \\ | ||
| + | Development environments are independent from production, lacking configuration, | ||
| === Outsourced Development === | === Outsourced Development === | ||
| - | Nested Knowledge | + | Nested Knowledge |
| === Supplier Adherence to SDLC === | === Supplier Adherence to SDLC === | ||
| - | Nested Knowledge | + | Nested Knowledge |
| + | |||
| + | * A review of technical documentation | ||
| + | * Does the platform/ | ||
| + | * Does the platform/ | ||
| + | * Does the solution advertise itself as production ready? | ||
| + | * A review of update / release history | ||
| + | * Does the supplier make regular updates for security patches | ||
| + | * 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 follow a standardized release versioning system? (e.g. SemVer) | ||
| + | * Are there reports of major version changes that weren' | ||
| + | * Does the solution include a public issue tracker? | ||
| + | * 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. | ||
| + | * Do all commits to the repository leave it in deployable condition? | ||
| + | * Are all commits reviewed & verified by a maintainer / peer? | ||
| + | * Is code well structured & organized? Does it compile? Does it have/pass a linter? | ||
| + | * Are new features / patches developed on branches or external to the main deployment branch? | ||
| + | * Does the solution minimize & verify its dependencies? | ||
| + | |||
| + | Per these criteria, the supplier is assessed for risk in inclusion | ||
| ==== Testing Procedures ==== | ==== Testing Procedures ==== | ||
| Line 52: | 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 72: | 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 80: | 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. | ||
| - | * The viability of the recommended patch is assessed. Developers will modify the application code as needed to accomodate | + | * The viability of the recommended patch is assessed. Developers will modify the application code as needed to accommodate |
| * If the vulnerability lacks a patch, the team may: | * If the vulnerability lacks a patch, the team may: | ||
| * 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|11/15/2021|Draft sent for approval| | + | |K. Cowie|01/24/2023|Reviewed| |
| - | |K. Holub|11/18/2021| | | + | |K. Holub|03/30/2023|Updating vulnerability scanning to include SecurityScorecard| |
| |K. Kallmes|11/ | |K. Kallmes|11/ | ||
| + | |P. Olaniran|9/ | ||
| + | |||
| + | [[: | ||
wiki/policies/dev.1639760426.txt.gz · Last modified: 2021/12/17 17:00 by katcow
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
