FOSSology

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting point. Size up to scan large packages or serve busier instances.

Set the NSG inbound rules to allow 22/tcp from your management network and 80/tcp for the FOSSology web interface. FOSSology serves plain HTTP on port 80, so terminate TLS in front of it with your own domain. The bundled PostgreSQL is never exposed. It listens on 127.0.0.1 only, so port 5432 stays off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal and choose Create a resource. Search the Marketplace for FOSSology by SecureAnyCloud, and select Create.

On Basics, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Review the dedicated data disk on the Disks tab. Then choose Review + create, and then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:fossology-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name fossology \
  --image sac1647283583153:fossology-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open port 80 for the FOSSology web interface:

az vm open-port --resource-group <your-rg> --name fossology --port 80

Step 3 - Confirm the services are running

SSH in as azureuser and confirm that PostgreSQL, Apache and the FOSSology scheduler are all active. PostgreSQL listens only on 127.0.0.1:5432, while Apache serves the web interface on port 80.

systemctl is-active postgresql apache2 fossology fossology-firstboot

Expected output:

active active active active

Confirm the listening sockets. Apache is public on :80, and PostgreSQL is loopback-only:

sudo ss -tlnp | grep -E ':80 |:5432 ' | awk '{print $1, $4}'

LISTEN 127.0.0.1:5432 LISTEN *:80

Step 4 - Retrieve the per-VM administrator password

First boot generates the administrator password for this specific VM and writes it to a root-only file. Read it over SSH:

sudo sed -E 's/^(FOSSOLOGY_ADMIN_PASSWORD=).*/\1********/' /root/fossology-credentials.txt | grep -E '^FOSSOLOGY'

FOSSOLOGY_URL=http://<your-vm-ip>/repo/ FOSSOLOGY_ADMIN_USER=fossy FOSSOLOGY_ADMIN_PASSWORD=<set-at-first-boot>

To see the real password value, read the file without the redaction: sudo cat /root/fossology-credentials.txt. The file is mode 0600 and owned by root, so only an administrator can read it.

Step 5 - Sign in to FOSSology

Browse to http://<your-vm-ip>/repo/. Sign in with user fossy and the per-VM password from Step 4. FOSSology ships no other usable login.

Step 6 - The FOSSology dashboard

After you sign in, you land on the Getting Started page. The top menu offers Home, Search, Browse, Upload, Jobs, Organize, Admin and Help. This is the hub for uploading packages, scheduling scans, browsing results and administering the instance.

Step 7 - Upload a package to scan

Choose Upload, then From File (or From URL or From Server), to add a source package.

Pick the analysis agents to run: Nomos and Monk for license scanning, Ojo for SPDX license identifiers, and Copyright/Email/URL/Author analysis. Then schedule the job.

The scheduler (fossology.service) runs the agents in the background. The results appear under Browse once the job completes.

Step 8 - The administration area

The Admin menu is where you manage users, groups, folders and the scan agents. The Edit User Account page shows the fossy account as a Full Administrator. From here you can set the account password, create additional users, and choose which analysis agents run by default.

Step 9 - No known or default credentials

The SecureAnyCloud image ships no usable default login. FOSSology's well known fossy / fossy default is replaced with a unique per-VM password, stored as a bcrypt hash with a per-user seed. The PostgreSQL role secret is rotated too. Confirm that the stored password is a bcrypt hash and that a seed is set:

sudo -u postgres psql -d fossology -tAc "SELECT user_name, left(user_pass,4) AS algo, (user_seed IS NOT NULL AND user_seed<>'') AS seeded FROM users WHERE user_name='fossy';"

fossy|$2y$|t

Now prove end to end that the per-VM administrator authenticates via the web login, while the default fossy / fossy and common weak guesses are rejected. The bundled round-trip check does exactly this:

sudo bash /usr/local/sbin/fossology-cred-roundtrip.sh

OK per-VM fossy authenticates via FOSSology web login; default + weak guesses rejected

You can also confirm that the per-VM password authenticates directly against the login endpoint. The command substitutes the password from the credentials file:

JAR=$(mktemp)
curl -s -o /dev/null -c "$JAR" -b "$JAR" "http://127.0.0.1/repo/?mod=auth"
curl -s -o /dev/null -c "$JAR" -b "$JAR" --data-urlencode "username=fossy" --data-urlencode "password=<FOSSOLOGY_ADMIN_PASSWORD>" "http://127.0.0.1/repo/?mod=auth"
curl -s -b "$JAR" "http://127.0.0.1/repo/?mod=user_edit" | grep -c "Edit User Account" || true rm -f "$JAR"

A count of 1 confirms that the per-VM administrator reached the admin-only User Account page.

Step 10 - Verify the stack and where your data lives

Confirm three things. The web interface answers, the reference license knowledge base is loaded, and both the PostgreSQL cluster and the FOSSology repository live on the dedicated data disk mounted at /data.

curl -s -o /dev/null -w 'GET /repo/ -> HTTP %{http_code}\n' http://127.0.0.1/repo/
sudo -u postgres psql -d fossology -tAc "SELECT concat(count(*),' reference licenses loaded') FROM license_ref;" findmnt -no SOURCE,TARGET,FSTYPE /data findmnt -no SOURCE,TARGET,FSTYPE /var/lib/postgresql

GET /repo/ -> HTTP 200 778 reference licenses loaded /dev/sdc /data ext4 /dev/sdc[/postgresql] /var/lib/postgresql ext4

The PostgreSQL cluster is bind-mounted onto /var/lib/postgresql from the data disk. The FOSSology repository, where uploaded packages and unpacked file trees are stored, sits at /data/fossology/repository. All of your scan data therefore lives on the dedicated disk and survives an operating system disk rebuild.

Adding your own domain and TLS

FOSSology is served over plain HTTP on port 80. Put a reverse proxy or load balancer in front of it that terminates TLS with your own certificate and domain, and restrict inbound 80/tcp to that proxy. The application needs no reconfiguration to sit behind a proxy at /repo/.

Security notes

• Limit network exposure. The web interface listens on :80. PostgreSQL listens on 127.0.0.1:5432 only and is never exposed to the network. Keep the NSG limited to 22/tcp from your management network and 80/tcp, ideally behind a TLS proxy.
• Rotate the administrator password. The administrator password and the database secret are unique per VM, generated on first boot, and stored in /root/fossology-credentials.txt (mode 0600). After your first sign-in, change the fossy password from the Admin area, or create your own named administrator and disable fossy.
• Keep the VM patched. The operating system is fully patched at build time, and unattended security upgrades remain enabled on the running VM.
• To apply updates manually, run sudo apt-get update && sudo apt-get upgrade.

Support

SecureAnyCloud images are backed by 24/7 support. For help with this image, email sales@secureanycloud.com.

Deploy on Azure

Launch FOSSology on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com