Many developers dread code reviews, and one reason for this is probably that most reviewers only offer criticism rather than encouragement. Remember as a peer reviewer, you can also reinforce things you see that are done well, which can be every bit as important and effective as nitpicking every design flaw, mistake, bug or styling issue.
There is an intrinsic value of positive reinforcement for encouraging desirable behavior.
Thou shalt not nag a developer
There is a bevy of static analysis tools that scan source code for common vulnerabilities. The anticipated desired behavior of a developer using these tools is to ascertain and fix any vulnerabilities discovered. Nagging or guilting engineers into fixing stuff is miserable for both sides.
Unfortunately, the results of such tools are almost always focussed on the negative, i.e. orienting it’s copywriting around implementation risks that can lead to exploits (your application is vulnerable to command injection, XSS, weak authentication, weak cryptography, privilege escalation, etc). Any implementation assessment that is positive in nature (good validation criteria and checks) is muted out as these tools are optimized/tuned to remove false positives.
Consequently, such tools become an automated security nitpicker with no positive reinforcement whatsoever
This is dangerous, for several reasons. It undercuts the effort and frustrates developers who spend hours writing code, and then rewriting it (fixing issues via pull requests), and rewriting it again. At times you can witness the stages of grief play out with a security vulnerability:
Anger → Denial → Bargaining → Disengagement/Acceptance.
Leading to this experience, developers often choose to ignore or disengage with these tools.
Rather than muting out observed good practices, can such tools, laud it?
Retooling for positive reinforcement
An optimal concoction of positive reinforcement with security risks would lead developers to continually engage with such security tools.
As an alum of Intuit, I was always in awe of TurboTax’s delightful experience which is primarily focussed on being goal-oriented rather than task-oriented.
Nobody is motivated to do their taxes for the sake of it. TurboTax knows this and instead orients its experience around the user’s true motivation: Get your maximum refund, guaranteed and accomplish it via milestones — now that’s a value proposition we can get behind.
Can application security tools be designed with goals in mind?
Of course, finding and fixing all vulnerabilities is NOT a measurable goal. As Dijkstra wisely put — “Testing shows the presence, not the absence of bugs”.
Our applications evolve continually so if we knew all the vulnerabilities we were searching for, it would obviate the need to look in the first place.
The journey of a product begins with source code, followed by its metamorphosis into features targeting consumer delight/value or bugs turning into vulnerabilities. Bugs are a side effect proxy for “observed example of insecurity” which often is a downside of breakneck-speed productivity.
The consequence of a bug can be classified into the following outcomes
- Exploited — The bug was not discovered or ignored leading to an attacker exploiting it to cause harm
- Undiscovered — The bug still lurks in code waiting to be exploited
- Found — Awareness of the bug as a consequence of discovery via code review, security tooling, security testing or ethical bounty hunting
- Preventative — What is found is fixed and checks are enforced such that it does not repeat again
Just as you can’t magically insert quality into a piece of software, you can’t sprinkle or mandate security features onto a design and expect it to become totally secure.
Can you imagine the stress of getting a critical security bug in your code? The stress is multiplied through murky and accusatory vulnerability reports demanding swift action.
From Security Bugs to Security Goals
As practitioners become aware of software security’s importance, they are increasingly adopting and evolving a set of best practices to address the problem.
Such best practices are defined by experienced architects within an organization or by subject matter experts in the developer community.
Such codified best practices are tangible measurements that naturally align with the notion of goal-orientation. Given that the software stack is composed of code modules, open source libraries and frameworks, it should help to answer a set of fundamental questions
— “If I use library X, what Y options should I incorporate to stay secure”
— “If I use web framework P, what Q configurations should I enable to stay secure”
Let’s exemplify this thought exercise by illustrating best practices around utilizing the popular Spring Boot’s security framework.
Listed below are some Spring Boot’s security framework practices recommended by Pivotal, HashiCorp, Atomist, Spring Framework and beachhead community members like Eugen from baeldung, Rod Johnson at Atomist, Mkyong, Arun Gupta from AWS and Chris Richardson:
- Always enable and extend WebSecurityConfigurerAdapter in your application
- Applying Authorization and Authentication checks on every public web route
- Enforce HTTPS transport security enforcement in production
- Enforce CSRF attack prevention
- Enforce Session Fixation protection
- Enforce Security Header Integration
i. HTTP Strict Transport Security for secure requests
ii. X-Content-Type-Options integration
iii. Cache-Control on static resources
iv. X-XSS-Protection integration
v. Clickjacking mitigation using X-Frame-Options - Password hashing enforcement
- Use of Spring Vault abstracting over Hashicorp Vault for accessing, storing and revoking secrets
- Use of OAuth2/JWT specification for authorization
Can such best practices be codified as a specification defined in adherence to how an open source framework or library should be used by its consumer?
Let us reimagine how TurboTax’s goal-oriented / actionable like experience would look like from the standpoint of an application using the spring boot security framework.
Note that the copywriting is optimized around a goal rather than a nitpicking list of vulnerabilities/risks.
Showing empathy through clear, concise, non-emotional bug reports free of FUD is critical. As a goal-oriented developer, one would ascertain feedback from such an experience and begin to iteratively fulfill all of these recommended best practices until his/her goal is accomplished.
While writing bug-free code is difficult it is even harder to prove that it is bug-free. Hence we define and continually evolve such a security specification for OSS software (libraries/frameworks) authored and driven by expert-led communities and thereafter use such a specification to measure its adherence or lack thereof from an application standpoint.
Sample Implementation of a Security Specification for Spring Boot Security
Enough said, let’s put this hypothesis to test using ShiftLeft’s Code Property Graph.
A sample microservice using Spring Boot security
Let’s leverage this project that I authored hosted in GitHub that is created on Spring Boot chassis with Spring security enabled.
A security specification to measure Spring Boot security’s effective utilization
The goal-oriented security specification using ShiftLeft’s Code Property Graph is published here:
This “Security-As-Code” specification can be integrated into your CI pipeline for continuous verification to ensure that all goals set forth are met iteratively.
(Video) Running specification against a sample application
The run sequence of a spring-boot-security specification either on your local machine or in your CI pipeline (Jenkins, TravisCI, CircleCI, GitHub Actions, GitLab CI) is illustrated below:
Results to power goal-oriented dashboard
The produced output (via API) can power a leaderboard goal-oriented UI across an organization.
In closing, security is an inherently cross-functional discipline. We have to work across many teams of varying qualities and enthusiasm. By leveraging the collective intelligence of OSS committers and subject matter experts we can create many more such security specifications (Apache Struts, Hadoop, Kafka, JWT, Play!, DropWizard, etc) that can be bundled with every OSS initiative.
This will hopefully prevent such debates and take us one step closer to goal-oriented security.
An alternate perspective — Supply Chain Specifications
My co-founder Manish Gupta passionately uses the analogy of supply chain and distribution management in the automotive industry.
The industry supply chain stretches from the producers of raw materials through to the assembly of the most sophisticated electronic and computing technologies.
The major component of the supply chain includes suppliers (tier 1–3), OEMs, distribution centers, dealers, etc. Most automotive OEMs create 25 to 30% of value internally and delegate the rest of 70% to their supplier chain.
Manufacturers (OEMs) purchased entire subassemblies, such as doors, power trains, and electronics from suppliers. The desire to work with partners to outsource subassemblies is leading to a radically new infrastructure to support the design, procurement, and logistics processes of the manufacturers in order to improve their innovative ability to get cars to market faster and reduce errors.
The operational success of OEMs and supplier chain hinges on published specifications i.e. specified dimensions, units and metrics defined by OEM that the supplier should adhere to in order to prevent errors which in turn reduces fatalities
In the world of software, the supplier chain comprises OSS/SaaS SDK developers who build software upon each other’s foundational elements and one or more such foundations are depended upon by an enterprise application suite.
Unfortunately there isn’t any specification available which precisely defines “How a particular framework / library / SDK should be used”. Documentation is a poor substitute for specification given that a specification defines metrics around a how a part should fit into the whole.
Imagine a world where specifications (like illustrated above with spring boot security, or how to use Twilio, Stripe API securely) is bundled with every possible open-source library or SDK.
When a software manufacturer depends on such a library, its specification is continually evaluated in the CI pipeline for adherence or lack thereof.
Failing to pass the specification would lead to risk of being exploited by adversarial entities.
This is fundamentally a new way to reason about software and its supply chain.
Originally published here — https://medium.com/@chetan_conikee/towards-a-concept-of-security-specification-for-software-supply-chain-a267a58e099d
Towards a concept of Security Specification for Software Supply Chain was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog – Medium authored by Chetan Conikee. Read the original post at: https://blog.shiftleft.io/towards-a-concept-of-security-specification-for-software-supply-chain-1fc8c66ae99e?source=rss—-86a4f941c7da—4
