back
8 comments
The name is unfortunate since there's already Vulnhub [1].

[1] https://www.vulnhub.com

Most of these compose files are pretty outdated AND they depend on non-standard builds of containers for each respective application.
What else would you expect for setups intentionally trying to preserve past versions of software?
Reproducibility in [Infosec] Software Research requires DevOpSec, which requires: explicit data and code dependency specifications, and/or trusting hopefully-immutable software package archives, and/or securely storing and transmitting crytographically-signed archival (container) images; and then Upgrade all of the versions and run the integration tests with a git post-receive hook or a webhook to an external service dependency not encapsulated within the {Dockerfile, environment.yml/requirements.txt/postBuild; REES} dependency constraint model.

With pip-tools, you update the python software versions in a requirements.txt from a requirements.in meta-dependency-spec-file: https://github.com/jazzband/pip-tools#updating-requirements

  $ pip-compile --upgrade requirements.in
  $ cat requirements.tct
Poetry has an "Expanded dependency specification syntax" but FWIU there's not a way to specify unsigned or signed cryptographic hashes, which e.g. Pipfile.lock supports: hashes for every variant of those versions of packages on {PyPI, and third-party package repos with TUF keys, too}.

From https://pipenv.pypa.io/en/latest/basics/#pipenv-lock :

  $ pipenv lock
> pipenv lock is used to create a Pipfile.lock, which declares all dependencies (and sub-dependencies) of your project, their latest available versions, and the current hashes for the downloaded files. This ensures repeatable, and most importantly deterministic, builds

"Reproducible builds" of a DVWA Deliberately Vulnerable Web Application is a funny thing: https://en.wikipedia.org/wiki/Reproducible_builds

Replication crisis https://en.wikipedia.org/wiki/Replication_crisis :

> The replication crisis (also called the replicability crisis and the reproducibility crisis) is an ongoing methodological crisis in which it has been found that the results of many scientific studies are difficult or impossible to reproduce. Because the reproducibility of empirical results is an essential part of the scientific method,[2] such failures undermine the credibility of theories building on them and potentially call into question substantial parts of scientific knowledge.

Just rebuilding or re-pulling a container image does not upgrade the versions of software installed within the container. See also: SBOM, CycloneDx, #LinkedReproducibility, #JupyterREES.

`podman-pull` https://docs.podman.io/en/latest/markdown/podman-pull.1.html... ~:

  podman image pull busybox 
  podman pull busybox
  docker pull busybox
  podman pull busybox centos fedora ubuntu debian
"How to rebuild and update a container without downtime with docker-compose?" https://stackoverflow.com/questions/42529211/how-to-rebuild-... :

  docker-compose up -d --no-deps --build #[servicename]
"Statistics-Based OWASP Top 10 2021 Proposal" https://dzone.com/articles/statistics-based-owasp-top-10-202...

awesome-vulnerable-apps > OWASP Top 10 https://github.com/vavkamil/awesome-vulnerable-apps#owasp-to... :

> OWASP Juice Shop: Probably the most modern and sophisticated insecure web application

And there's a book, an Open Source Official Companion Guide book titled "Pwning Juice Shop": https://github.com/juice-shop/juice-shop#official-companion-...

If the versions installed in the book are outdated, you too can bump the version strings in the dependency specs in the git repo and send a PR Pull Request (which also updates the Screenshots and Menu > Sequences and Keyboard Shortcuts in the book&docs); and then manually test that everything works with the updated "deps" dependencies.

If it's an executablebooks/, a Computational Notebook (possibly in a Literate Computing style), you can "Restart & Run all" from the notebook UI button or a script, and then test that all automated test assertions pass, and then "diff" (visually compare), and then just manually read through the textual descriptions of commands to enter (because people who buy a Book presumably have a reasonable expectation that if they copy the commands from the book to a script by hand to learn them, the commands as written should run; it should work like the day you bought it for a projected term of many free word-of-mouth years.

From https://github.com/juice-shop/juice-shop#docker-container :

  docker pull bkimminich/juice-shop
  docker run --rm -p 3000:3000
With podman [desktop],

  podman pull bkimminich/juice-shop
  podman run --rm -p 3000:3000 -n juiceshop0
I have read this multiple times and can still not figure out what you are trying to say and how it is related to OPs comment...
> Most of these compose files are pretty outdated AND they depend on non-standard builds of containers for each respective application.

>> What else would you expect for setups intentionally trying to preserve past versions of software?

So, I wrote about reproducibility in software; and Software Supply Chain Security. Specifically, how to do containers and keep the software versions up to date.

Are you challenging the topicality of my comment on HN - containing original research - to be facetious?

Also, the install instructions suggest installing the python implementation of docker-compose, which has been deprecated in favour of the compose docker plugin.
I still use the python one out of habit.