Application Security does not live by itself! It is one of the many attributes that we are concerned with in a modern software-based product. These adjacencies are important because, on one hand they are part of the justification for the application security program; on the other hand they help by sharing cost and sometimes tools.
This Application Security For All framework chooses to classify these activities as adjacencies to provide a little more focus on the core elements; Other Frameworks incorporate one or more of them explicitly.
Privacy
Privacy is concerned with the proper management of data about people (typically users). It has become a heightened concern in light of EU GDPR (General Data Protection Regulation) which took effect in 2018. Security is explicitly addressed by GDPR with a requirement that organizations put “appropriate measures” in place. At a more concrete level security is an important part of a layered implementation of data privacy; it is a necessary but not sufficient mechanism to meet modern data privacy requirements.
Source Code Management
Source code management is one of the last lines of defense against direct supply chain attacks such as the infamous SolarWinds attack in 2020. The perpetrators were able to make subtle changes to SolarWinds source code supporting the intrusion of systems running a corrupted version of the resulting product. There are a few questions to ask:
- Can code be committed anonymously?
- What sort of authorization and authentication mechanisms are in place for code repository users?
- Is committed code subject to human code reviews? Do the tools enforce this?
3rd Party Code Management
Most modern software systems incorporate 3rd party components – often Open Source. This 3rd party software is all licensed in some fashion or the other. The licensing terms frequently demand that the use of the software be publicly recognized and may have additional onerous requirements. This all needs to be managed. One aspect of this is understanding and managing the version of the 3rd party software being used; this is where Application Security enters the picture. This 3rd party software may contain known vulnerabilities. In fact the biggest threat to a system will often come from vulnerabilities in software it incorporates rather than software the team actually writes.
DevOps
DevOps is concerned with the automated building, testing, and deployment of systems. The most obvious tie with Application Security is with the incorporation of Security Related Tools into development pipelines. Another important aspect of DevOps is that it reduces the pain associated with moving to new versions of 3rd party software by automating the testing and possibly deployment of these changes.
You will also see the term DevSecOps used to refer to the integration of application security tools and DevOps. It hardly seems we need a new acronym for something so obvious, but it is out there.
Software Upgrade Processes
It is almost inevitable that deployed software will be found to have vulnerabilities; most often due to new vulnerabilities discovered in 3rd party software. Occasionally there is a work-around such as “close this port,” but more generally the only recourse is to upgrade the production software. Easy upgrades support application security and difficult ones hinder it. In fact a sufficiently problematic upgrade process may make most of the rest of an Application Security program mute. Who cares how good your current practice is if half your customers are stuck with 3 year old software? Here are a few things to consider:
- Is easy upgrade something that is ‘built in’ to the design?
- Are there mechanisms to patch an existing product? A patch is essentially a special form of upgrade with its own set of concerns.
- Do we even know what versions of our product are in production use?
- How do we test upgrades?
- Have we built-in a fallback mechanism?
- Are we upgrading a customer-controlled system, a managed (e.g. Cloud) service, or possibly both?
Code Quality
Code Quality is a somewhat nebulous notion in the “I know it when I see it” realm. That said, there are some concrete attributes of “high quality” code:
- It tends to be easier to understand and modify
- It tends to have lower defect density
- It follows consistent coding conventions
- It is well-structured
All of this is congruent with Application Security (and more specifically secure coding practices). Developers are less likely to make inadvertent mistakes and code reviewers are more like to spot both mistakes and the exceedingly rare intentional corruption. There is also an overlap on the Tools front: the same static analysis tools that identify 1st class security concerns often identify code quality issues that are not directly related to security.
Security-Related Features
These are aspects of the system that are visible to end-users and/or administrators. Examples include password management controls, single sign-on integrations, multi-value authentication, event logging, and many others.
IT Security
In the context of Application Security, IT Security is concerned with securing the development environment. This starts with insuring that developers are properly authenticated and authorized. Then with making sure that the various repositories are protected.