Project Aegis | Cybersecurity Lab Sometimes the most interesting vulnerability isn't hidden in the files a service exposes. It's hidden in the service itself. During a recent Project Aegis lab session, I started with what looked like a fairly uninteresting FTP service on a deliberately vulnerable Metasploitable 2 virtual machine. Anonymous FTP login worked. The root directory appeared empty. There were no obvious files to download and nothing immediately interesting to enumerate. Yet, within the same service, I eventually obtained a root shell . The journey was a useful demonstration of a complete vulnerability-assessment workflow: reconnaissance → service identification → vulnerability research → automated validation → source inspection → manual reproduction → exploitation → impact verification Most importantly, it reinforced a lesson I want Aegis to teach: Don't just run security tools. Understand what they're actually doing. The Lab For this experiment, I used an ...
Modern Spring Boot applications rarely remain simple for long. A project may begin with a few entities and a handful of tables, but as it evolves, database schemas change continuously: columns are added, indexes are introduced, constraints change, new tables appear, and sometimes data itself needs to be transformed. The challenge isn't creating these changes. The challenge is making sure the same changes are applied consistently across every environment . This is where Flyway comes in. Flyway provides a versioned, repeatable mechanism for evolving a relational database schema alongside application code. When integrated with Spring Boot, it allows database changes to become part of the application's lifecycle and, eventually, the CI/CD deployment pipeline. In this article, we'll explore Flyway from the ground up and build a Spring Boot + PostgreSQL setup using migrations. 1. The Problem: Database Schema Changes Imagine a Spring Boot application initially has: users projec...