We have endeavored to make the application as easy to run as possible by focusing on some basic tools and technologies that almost every Spring developer would have on their development machine. Nevertheless, we have provided the Getting started section as supplementary information in the Append, Getting Started with JBCP Calendar Sample Code.

The primary method for integrating with the sample code is providing Gradle--compatible projects. Since many IDEs have rich integration with Gradle, users should be able to import the code into any IDE that supports Gradle. As many developers use Gradle, we felt this was the most straightforward method of packaging the examples. Whatever development environment you are familiar with, hopefully, you will find a way to work through the examples in this book.

Many IDEs provide Gradle tooling that can automatically download the Spring and Spring Security 4.2 Javadoc and source code for you. However, there may be times when this is not possible. In such cases, you'll want to download the full releases of both Spring 4.2 and Spring Security 4.2. The Javadoc and source code are top-notch. If you get confused or want more information, the samples can provide an additional level of support or reassurance for your learning. Visit the Supplementary Materials section, in Appendix, Additional Reference Material to find additional information about Gradle, including running the samples, obtaining the source code and Javadoc, and the alternatives for building your projects without Gradle.

Let's return to our email and see how the audit is progressing. Uh-oh, the results don't look good:

APPLICATION AUDIT RESULTS

This application exhibits the following insecure behavior:

• Inadvertent privilege escalation due to lack of URL protection and 
general authentication
• Inappropriate or non-existent use of authorization
• Missing database credential security
• Personally-identifiable or sensitive information is easily accessible 
or unencrypted
• Insecure transport-level protection due to lack of SSL encryption
• Risk level is high

We recommend that this application should be taken offline until these issues can 
be resolved.

Ouch! This result looks bad for our company. We'd better work to resolve these issues as quickly as possible.

Third-party security specialists are often hired by companies (or their partners or customers) to audit the effectiveness of their software security, through a combination of white hat hacking, source code review, and formal or informal conversations with application developers and architects.

White hat hacking or ethical hacking is done by professionals who are hired to instruct companies on how to protect themselves better, rather than with the intent 
to be malicious.

Typically, the goal of security audits is to provide management or clients with the assurance that basic secure development practices have been followed, to ensure the integrity and safety of the customer's data and system functions. Depending on the industry the software is targeted at, the auditor may also test it using industry-specific standards or compliance metrics.

Receiving the results of a security audit can be an eye-opening experience. Following through with the required software improvements can be the perfect opportunity for self-education and software improvement, and can allow you to implement practices and policies that lead to secure software.

Let's review the auditor's findings, and come up with a plan to address them 
in detail.