diff --git a/content/engineering/languages-runtimes/python.md b/content/engineering/languages-runtimes/python.md
index b0727d1e..29de4625 100644
--- a/content/engineering/languages-runtimes/python.md
+++ b/content/engineering/languages-runtimes/python.md
@@ -41,6 +41,7 @@ When using [Django], we **default** to starting with the most recent [Long Term
 Otherwise, our **standard** practice is to use the latest release of our libraries when first installing. Security updates (as indicated by GitHub or Snyk) should be applied ASAP, but all libs should be updated at some routine interval (e.g. quarterly).
 
 Finally, in an effort to ensure our deployments are repeatable, our code **standards** require all dependencies (including dependencies' dependencies) be pinned to specific versions. This should also apply to the development environment (e.g. linters, testing tools, etc.) **Suggestions** for implementing that include
+* [poetry](https://python-poetry.org/)
 * [pip-tools](https://github.com/jazzband/pip-tools)'s `pip-sync`
 * [pipenv](https://github.com/pypa/pipenv)'s `Pipfile.lock`
 * [vendoring dependencies](https://docs.cloudfoundry.org/buildpacks/python/index.html#vendoring)
@@ -51,6 +52,10 @@ Our **standard** tool for ensuring consistency across Python code bases is [flak
 
 Use [Black](https://black.readthedocs.io/en/stable/) for automatic code formatting.
 
+You are welcome to use [Ruff](https://github.com/astral-sh/ruff) instead as it
+combines all of the above packages into one and runs faster. It may become our
+standard in the future.
+
 Using Code Climate to measure complexity scores (by way of [radon](https://pypi.python.org/pypi/radon)) is also a reasonable **default** to ensure you see potentially confounding functions and classes.
 
 ## Libraries
@@ -68,6 +73,6 @@ The Python ecosystem is large and full of alternative solutions to similar probl
 ## Type support
 Python 3.5 and beyond have had partial support for static type hints. Static typing can both make code authors' intent clearer and reduce the number of bugs through static analysis. It's also notorious for slowing down the pace of prototyping and requiring a great deal of boiler-plate.
 
-Given this state, we believe it's reasonable to **default** to using type annotations when they make your intent clearer (i.e. as a form of documentation). We **suggest** using a static analysis tool (such as [mypy](http://mypy.readthedocs.io/en/latest/)) to catch logic bugs, but only where it's practical. Consider a white-list of files to run against.
+Given this state, we believe it's reasonable to **default** to using type annotations when they make your intent clearer (i.e. as a form of documentation). We **suggest** using a static analysis tool (such as [mypy](http://mypy.readthedocs.io/en/latest/)) to catch logic bugs, but only where it's practical. Consider an allowlist of files to run against.
 
 [Django]: https://www.djangoproject.com/
diff --git a/content/engineering/security/content-security-policy.md b/content/engineering/security/content-security-policy.md
index 4b4cba0a..27c020d3 100644
--- a/content/engineering/security/content-security-policy.md
+++ b/content/engineering/security/content-security-policy.md
@@ -119,11 +119,11 @@ However, there are scenarios in which you may want to use an inline content tag,
 Another potential issue is third-party libraries that automatically inject JavaScript and CSS into your HTML. If your project utilizes a library that does this, the only guaranteed solution is
 to use the `unsafe-inline` value when setting the `script-src` directive; this obviously defeats the purpose of having a CSP for your JavaScript.
 
-If you must load external scripts inline and are not allowed to use the `unsafe-inline` keyword, you could also make a SHA hash of the script being included, and whitelist that in your content security policy.
+If you must load external scripts inline and are not allowed to use the `unsafe-inline` keyword, you could also make a SHA hash of the script being included, and allowlist that in your content security policy.
 
 This technique will allow those scripts to load, with the following caveats:
 
-* Each the time the third-party script changes, a new hash will have to be computed, and your policy's `script-src` whitelist will need to be updated
+* Each the time the third-party script changes, a new hash will have to be computed, and your policy's `script-src` allowlist will need to be updated
 * Inline the SHAs of multiple scripts adds bloat to the policy, and increases the number of bytes needed to transmit the header to the browser.
 
 As each project has its own needs, you should always perform your own research on a per-project basis to determine the best way to handle third-party scripts!