That's why software security is hard and requires a systematic approach with continuous execution. In my experience in working on software security, I find that different groups of people usually care about or emphasize different aspects of software security. Depending on a situation, prioritizing one security aspect over another might make sense, but in order to evaluate an overall security of a product, generally, they all need to be considered together. More specifically, I believe that there are four main areas that need to be addressed in order to build secure software that can also can be deployed and used securely:
- a security stance
- secure software
- security features
- security documentation
Having a security stance means to have a clear story about a product's security architecture and risks, security controls, hardening and limitations. A well-defined security stance helps maintaining and improving security of the product as new features are implemented and deployed. To build secure software, i.e. software that can withstand malicious attacks, security should be built in into its development lifecycle. More specifically, there should be a continuous process of evaluating and managing security risks (new and old), taking them into consideration and addressing in the architecture, design, implementation, testing, and deployment of software. It's important to note that this applies not only to new feature or functionality, but also to the entire product as any addition has an associated security risk and potential consequences on the overall security of the system. Building security into software development lifecycle is a complex and perhaps the most time consuming component of software security as it's the only way to ensure that everything else (i.e., the security stance, features and documentation) holds.
To use the iceberg analogy, the security stance and how security of a software is ensured are the fundamental parts of security but they are are mostly invisible to end users. In fact, I'd speculate that they are not that much appreciated and often overlooked by a general public. They're often assumed to be given until something goes wrong. What users usually see and appreciate is features and functionality. Together with documentation they make up the tip of the iceberg. While security features are obviously necessary, they should not be mistaken for software security. It's not a number of features that matters, but correctness of their design and implementation and their contribution to overall security of the product. Each piece of software should have a set of fundamental security features, such as authentication and authorization, and a set of features that are necessary for its secure usage and deployment given its purpose and design.
Documentation is another important aspect of software security. Providing an end user with a clear explanation of the supported security controls and features and architectural constraints is truly essential to the security of the final deployed product. Documentation helps users to evaluate, understand, correctly use and improve on available security controls. In fact, lack of proper documentation can hurt security of a system if less secure options are chosen due to lack of user understanding of available controls.