Historically, security has been enforced outside of the application, particularly at the edge of the network where traffic flows across trusted and untrusted network segments. This is accomplished by using various tools such as network or application specific firewalls (e.g. web application firewalls, or email gateways) that would analyze traffic and look for malicious payloads. In addition, vulnerability scanners, intrusion and malware detection tools have been used to scan for suspicious content or activity, raising alerts or at best resulting in some form of blockage or quarantine.  

These controls act from outside of the application and do not have the visibility from the inside required to truly understand what is taking place or whether the perceived attack was successful or not. For example, an IDS or vulnerability scanner may observe a security issue based on the configured rules or attack signatures and raise an alert, however, due to a lack of a view from within the application, such tools cannot determine with 100% certainty as to whether the attack succeeded or not. Having an internal view from within paints the most accurate picture of potential security issues, as opposed to an outsider view which is a good guess at best. 

In addition, statistics have shown that bolting security as an afterthought to the application is more expensive than taking security controls into consideration early on and “baking” them in. Applications should be architected and designed with security in mind, where all possible threat scenarios are considered and mitigating controls as well as compliance requirements are built-in. In doing so, more secure applications are produced, costly inefficiencies are avoided, and organizations receive a better return on their investment. 

This does not mean that security controls outside of the application are not needed, as security should follow a defence in depth approach and be applied at all layers where possible.  


As the focus on security shifts to the application layer, one of the key concerns is use of packages and libraries used within those applications. One of the advantages of modern-day software development is access to a vast array of modules, packages, and libraries that can extend the features and functionality provided by the core language or framework used to build applications.  

While this provides great benefits and flexibility, it brings about challenges when it comes to security. Many of these packages are Open Source, created by multiple contributors and may not go through a strict security review process, resulting in undetected vulnerabilities. In addition, packages that have gone through a security assessment in the past, may be contain new vulnerabilities that are not yet known and will not be detected by existing tools and processes.  In order to address these issues, organizations should enforce policies to prevent use of vulnerable packages, modules and libraries, maintain an up-to-date inventory of packages used by applications, and perform regular checks for vulnerabilities based on trusted sources of information. If any of the packages are found to contain a vulnerability, patches must be applied, and new versions deployed. 


In conclusion, “baking” security into the application and having an insider real-time view from within can provide an accurate picture, allow enforcement of the required policies, and assist in maintaining inventory and addressing vulnerable packages as early as possible.