Artemis Financial is a consulting company that builds individualized financial plans for their customers, covering savings, retirement, investments, and insurance. They had a RESTful web API that needed to be modernized, and the main issue they wanted addressed was software security. Their existing codebase had no encryption, no authentication, outdated dependencies with known critical vulnerabilities, and basic coding issues like hardcoded credentials. For a company handling sensitive financial data, that's a serious problem, both from a compliance standpoint (GLBA, SOX, PCI DSS) and from a basic "our customers trust us with their money" standpoint.
The strongest part of my work was the manual code review in the vulnerability assessment. I went through the codebase line by line and identified ten distinct security findings, from hardcoded database credentials in DocData.java to missing input validation on the deposit() method that could let someone pass in negative values. I was pretty thorough about documenting the exact location, severity, and the actual code snippet for each finding rather than giving vague descriptions.
Coding securely matters because the cost of getting it wrong is massive. For a company like Artemis Financial, a breach doesn't just mean bad press. It means regulatory fines, lawsuits, and customers losing real money. Software security is a direct contributor to a company's overall well-being because it protects revenue, maintains customer trust, and keeps the business compliant with regulations that could otherwise shut it down.
The dependency check portion was both challenging and helpful. Running the OWASP Dependency-Check tool against the Maven project initially felt straightforward, but interpreting the results took some work. The project had over 40 CVEs across its dependencies, and figuring out which ones were actually exploitable in context versus just theoretical risks required understanding how each library was used. For example, the Tomcat Ghostcat vulnerability (CVE-2020-1938) was critical on paper, but its exploitability depended on whether the AJP connector was enabled. That kind of contextual analysis was something I got better at through this course. The false positive suppression exercise in Module 6 also helped me understand that not every flagged CVE is a real threat, and learning to document those decisions in a suppression.xml is a practical skill.
I increased security across multiple layers. At the transport layer, I implemented HTTPS using a self-signed certificate generated with Java keytool and configured Spring Boot to serve over SSL on port 8443. At the application layer, I implemented SHA-256 checksum verification to ensure data integrity. At the dependency layer, I ran OWASP Dependency-Check scans and addressed vulnerable libraries, including creating suppression rules for confirmed false positives and updating the pom.xml configuration.
In the future, I'd continue using OWASP Dependency-Check integrated into the CI/CD pipeline so it runs on every build. For deciding on mitigation techniques, I'd reference the OWASP Top 10 and the Secure Coding Practices Quick Reference Guide as starting points, then assess each vulnerability based on the specific application context. Static analysis tools like SpotBugs or SonarQube would also be useful for catching code-level issues that a dependency scanner misses.
After refactoring the code, I verified both functionality and security through a few steps. I ran the application and confirmed it served correctly over HTTPS at https://localhost:8443/hash, verifying that the SHA-256 checksum endpoint returned the expected hash value. I then re-ran the OWASP Dependency-Check to make sure my changes didn't pull in new vulnerable dependencies. Comparing the before and after dependency reports was key to confirming I hadn't introduced new issues while fixing old ones. I also did a clean Maven build to check for compilation errors and reviewed the Spring Boot console output for any warnings.
Several tools and practices from this course will stick with me. The OWASP Dependency-Check Maven plugin is something I plan to use in any Java project going forward, and the concept applies to other ecosystems too (npm audit, pip-audit, etc.). The Java keytool for certificate generation and the Spring Boot SSL configuration are practical skills for any web application. The vulnerability assessment process flow diagram from the course materials was also a solid framework for systematically evaluating where security applies in an application. And honestly, just the habit of reading CVE descriptions and understanding severity scores is something I didn't have before this course.
For future employers, the vulnerability assessment report is the most valuable artifact from this course. It demonstrates that I can systematically review a codebase for security issues, use industry-standard tools to identify dependency vulnerabilities, prioritize findings by severity, and create actionable remediation plans. The report shows both manual code review skills and automated tooling knowledge. In a field where security breaches make headlines regularly, being able to show that you can assess and improve the security posture of an application is directly relevant to almost any development role.