Securing software supply chains has become a first-class consideration — along with coding and CI/CD pipelines — when developing a software product. Far too many vulnerabilities have been subliminally introduced into software products and resulted in catastrophic breaches for us as diligent developers to treat supply chain security as an afterthought. The core practices and principles outlined in this Refcard provide a foundation for creating secure supply chains that produce deliverables and products that others can trust.
Enterprises are rapidly adopting cloud-native architectures and design patterns to help deliver business values faster, improve user experience, maintain a faster pace of innovation, and ensure high availability and scalability of their products. Cloud-native applications leverage modern practices like microservices architecture, containerization, DevOps, infrastructure-as-code, and automated CI/CD processes.
This Refcard will walk through the critical challenges of cloud-native application security, demonstrate how to build security into the CI/CD pipeline, and introduce the core patterns and anti-patterns of cloud-native application security.
Advances in developer tools, containers, code repositories, and more enable developer teams to deliver software at an unprecedented pace. However, application security teams are often understaffed, underfunded, and laboring to keep pace with software development. One demonstrated strategy that helps AppSec teams keep up and even provides them time for high-value security tasks is to shift security left in the development cycle.
Creating a developer-first approach to security, or in other words, shifting security left requires that developers become accountable for producing secure code. Since security is not the typical developer's area of expertise, application security engineers assume the role of providing oversight and guidance needed to enable developers to succeed.
In an ideal world, secret detection tools would spot all leaked secrets and never report false positives.
Unfortunately -or maybe fortunately...- we do not live in an ideal world: secret detection tools are not perfect, sometimes they report false positives. But would it really be better if they did not?
The WordPress content management system (CMS) is popular with communities, e-commerce stores, educational websites, and blogs because of its flexibility and support to a variety of use-cases. The free, open-source CMS is also supported by advanced plugins that enable users to customize the look and feel of their websites.
Besides this, WordPress is supported by a global community of volunteers who develop plugins and themes, making it easy to learn, adapt, and scale quickly. While it is convenient and reliable for most website projects, WordPress requires strict observation of best practices to keep sites secure. In addition, since WordPress runs on open-source code, thousands of contributors take time to find, identify, and fix WordPress security issues.
In today’s software development culture, there is an ever-increasing need for management to drive empowerment within their teams. You need to seek out, identify, and empower someone who can act as your team’s security champion. Find at least one champion to start, and add more if they are available. As you grow, you may even consider assembling a Security Champions team.
What Makes a Security Champion?
Security champions should have some security background or knowledge of cyber security, as well as being willing, able, and motivated to learn much more. Your champion can be a current team member or a qualified contractor/consultant, he/she has to have a deep knowledge of the team’s goals is necessary. A security champion needs to be a positive person that can offer diligent observations and constructive suggestions to the team.
Digital transformation and the speed at which applications are developed and deployed is moving at a rapid pace. Businesses have always competed to see who can be the first to respond to customer needs, mainly in hopes of capturing some of a competitor’s market share. DevOps and the cloud have enabled software development to move from the annual updates of yesteryear to shipping releases daily to what we now call continuous delivery (CD).
Unfortunately, the security industry has fallen behind in its ability to keep pace with modern developer teams in many ways. It may be more accurate to say security was left behind. As developers assumed ownership of applications through development and operations, security was left in a silo — a gatekeeper expected to review code, find vulnerabilities, and send the results back to the developer team for remediation.
The huge advances in 'Shift Left' processes makes it possible to deliver code to production that is secure and largely free from vulnerable dependencies. Among other things, these processes typically involve matching dependencies against public vulnerability lists from Mitre, Red Hat, Debian, and other projects.
'Shift Left' Scanning Alone Does Not Go Far Enough to Identify Production Vulnerabilities
Vulnerability lists don’t stand still. CVEs are published through the NVD at a rate of about 50 per day, so the risk of a new vulnerability being found in production is significant. Furthermore, third-party production components may not be scanned in a way that is as rigorous or up-to-date as you would like.
Threat modeling is the ultimate shift left approach. It can be used to identify and eliminate potential vulnerabilities before a single line of code is written. Employing threat modeling methodologies should be your first step toward building networks, systems, and applications that will be secure by design. STRIDE is a model of threats that can be used as a framework in ensuring secure application design.
STRIDE - Threat Modeling Methodology
![STRIDE threat modeling]()
As technology continues to become more relevant for businesses worldwide, the importance of securing business-critical applications and their underlying tech stack continues to gain prominence. With the changing threat landscape, it is often impractical to identify vulnerabilities in real-time by simply leveraging automated tools. To help with this, ethical hacking has been steadily gaining popularity on account of its effectiveness in simulating real-world attacks and identifying gaps.
This article explores what ethical hacking is, the five stages of the ethical hacking process and addresses commonly asked questions.
A recently published paper provides a logo and slick polish for an old vulnerability about the ability of certain Unicode characters to render differently for human reviewers than the machines that execute the instructions.
- The code may intend to confuse a human reader to misunderstand the code based on how the compiler reads encoding (specifically Unicode characters). The intended result would be to execute something that an unconfused human would not allow.
- A human code reviewer using a plain-text editor or editor with inaccurate syntax highlighting may miss the impact of these control characters. Most IDEs and code editors utilize parse trees and make the Unicode characters visible so that it’s easier for someone to understand.
- Developers discussing this Trojan Source vulnerability may use the opportunity to saddle up on horse puns.
What Is the Trojan Source?
The Trojan Source is a combination of Unicode control characters that intend to confuse a human into thinking the code does one thing while getting the machine to do another. Mainly it involves the ability to change certain control characters like switching right-to-left encoding or to encode similar-looking letters in different character sets.
Open-source is everywhere, it is one of the driving forces of software innovation from the academic to the enterprise world (75 percent of codebases audited by Synopsys in the 2021 OSSRA report rely on open-source components). Its prevalence in commercial software is reaching unprecedented levels, to the extent that the European Commission has recently identified it as a public good in a recent study assessing its impact on the region’s economy.
But the interstitial nature of open-source in modern software also makes it a subject of security and compliance concerns, as it is capable of exposing organizations that use it to a host of unknown risks and vulnerabilities. Most discussions we are hearing today around security in this space are focused on the identification, fixing, and remediation of vulnerabilities — all seen from the “consumer” perspective.
Editor's Note: The following is an article written for and published in DZone's 2021 Application Security Trend Report.
In today’s technology landscape, organizations are supported by web applications that act as essential enablers to streamlining operations. While these applications enable automation, wider collaboration, and ease of sharing data, they also act as vectors that are prone to malicious attacks. Besides this, as modern applications rely on loosely connected components and services in constant communication, security becomes a complex, time-consuming challenge.
Editor's Note: The following is an article written for and published in DZone's 2021 Application Security Trend Report.
Organizations and individuals face an ever-increasing threat from a wide variety of actors. Threats can come from nation states, organized crime gangs, or even determined individuals. These attacks come in the forms of ransomware, which can cripple your business and cause data loss or data exfiltration. Beyond ransomware, more insidious attacks like the SolarWinds supply chain attack can impact a large number of organizations beyond the initial attack victim. A supply chain attack looks for weak links in the business process — in this case, pursuing a network monitoring vendor whose software is widely used and inherently needs to run with high privileges.
Introduction
Spring security provides a mechanism to control and limit the maximum number of single-user open sessions. This mechanism prevents users from exceeding the number of allowed simultaneous connections. For example, Netflix limits the number of screens you can watch at the same time according to your subscription plan.
In part 1, we will understand how this mechanism works, how to use it, and being aware of the default spring security implementation limitations. In part 2, we will see how to overcome those limitations in a clustered environment.
The financial services industry has seen a prolific rise in the use of applications in the last couple of years. Globally millions of customers already use a wide range of mobile app services, and it is estimated that the financial application industry will grow at a rate of 30% in the coming years.
In 2020 there were 26% more mobile app sessions as compared to 2019. Using applications for different financial and banking services is a rapid and convenient way to effectively manage your monetary resources like checking balance, transferring funds, paying bills, and so on.
As mentioned in my previous post "Building Software Immunity," an application security mindset needs to be at the core of software development practices. Just as good eating habits bring nutrients into our bodies, good development practices bring internal quality and immunity into our software to help fight off any unforeseen attacks in future. This post is an attempt to explore some of these ideas and practices that can help developers or tech leads make software and, eventually, the end users secure.
Shift-Left Approach
With the rise of Twelve-Factor cloud native applications, infrastructure has become part of software applications. Development teams (leads, software developers, product owners) are building software![]()
rapidly with various CI/CD (DevOps) and IaC (Infrastructure As Code) tools. In such agile and evolving environments, security of the software can be easily overlooked. As pointed out by Richard Seiersen in A Modern Shift-Left Security Approach, incorporating security in early phases of software development has typically been costly and time-intensive. An improved approach is to embrace security features right from the beginning when requirements are formed. That is, security requirements can be augmented with user stories to emphasize these aspects in rapid development environments (for more directions, refer to C1: Define Security Requirements | OWASP).
![Meme of a woman starting to fall asleep before her brain tells her, "You committed the API Keys to a public repo."]()
Image is sourced from DZone's Twitter
As a developer, I admit that I’ve committed secrets to public Github repositories before. Hardcoded secrets have always been a problem in organizations and are one of the first things I look for during a penetration test. When developers write secrets such as passwords and API keys directly into source code, these secrets can make their way to public repositories or application packages, then into an attacker’s hands.
Image is sourced from