Nov 19 2021

DuckDuckGo Wants to Stop Apps From Tracking You on Android

Category: App Security,Information Privacy,Information Security,Web Security — DISC @ 4:23 pm

At the end of April, Apple’s introduction of App Tracking Transparency tools shook the advertising industry to its core. iPhone and iPad owners could now stop apps from tracking their behavior and using their data for personalized advertising. Since the new privacy controls launched, almost $10 billion has been wiped from the revenues of Snap, Meta Platform’s Facebook, Twitter, and YouTube.

Now, a similar tool is coming to Google’s Android operating system—although not from Google itself. Privacy-focused tech company DuckDuckGo, which started life as a private search engine, is adding the ability to block hidden trackers to its Android app. The feature, dubbed “App Tracking Protection for Android,” is rolling out in beta from today and aims to mimic Apple’s iOS controls. “The idea is we block this data collection from happening from the apps the trackers don’t own,” says Peter Dolanjski, a director of product at DuckDuckGo. “You should see far fewer creepy ads following you around online.”

The vast majority of apps have third-party trackers tucked away in their code. These trackers monitor your behavior across different apps and help create profiles about you that can include what you buy, demographic data, and other information that can be used to serve you personalized ads. DuckDuckGo says its analysis of popular free Android apps shows more than 96 percent of them contain trackers. Blocking these trackers means Facebook and Google, whose trackers are some of the most prominent, can’t send data back to the mothership—neither will the dozens of advertising networks you’ve never heard of.

From a user perspective, blocking trackers with DuckDuckGo’s tool is straightforward. App Tracking Protection appears as an option in the settings menu of its Android app. For now, you’ll see the option to get on a waitlist to access it. But once turned on, the feature shows the total number of trackers blocked in the last week and gives a breakdown of what’s been blocked in each app recently. Open up the app of the Daily Mail, one of the world’s largest news websites, and DuckDuckGo will instantly register that it is blocking trackers from Google, Amazon, WarnerMedia, Adobe, and advertising company Taboola. An example from DuckDuckGo showed more than 60 apps had tracked a test phone thousands of times in the last seven days.Most Popular

My own experience bore that out. Using a box-fresh Google Pixel 6 Pro, I installed 36 popular free apps—some estimates claim people install around 40 apps on their phones—and logged into around half of them. These included the McDonald’s app, LinkedIn, Facebook, Amazon, and BBC Sounds. Then, with a preview of DuckDuckGo’s Android tracker blocking turned on, I left the phone alone for four days and didn’t use it at all. In 96 hours, 23 of these apps had made more than 630 tracking attempts in the background.

Using your phone on a daily basis—opening and interacting with apps—sees a lot more attempted tracking. When I opened the McDonald’s app, trackers from Adobe, cloud software firm New Relic, Google, emotion-tracking firm Apptentive, and mobile analytics company Kochava tried to collect data about me. Opening the eBay and Uber apps—but not logging into them—was enough to trigger Google trackers.

At the moment, the tracker blocker doesn’t show what data each tracker is trying to send, but Dolanjski says a future version will show what broad categories of information each commonly tries to access. He adds that in testing the company has found some trackers collecting exact GPS coordinates and email addresses.

“You should see far fewer creepy ads following you around online.”

PETER DOLANJSKI, DUCKDUCKGO

DuckDuckGo Wants to Stop Apps From Tracking You on Android

Tags: Apps From Tracking, DuckDuckGo

Oct 07 2021

Divide Between Security, Developers Deepens

Category: App Security — DISC @ 9:16 am
Divide Between Security, Developers Deepens

Security professionals work hard to plan secure IT environments for organizations, but the developers who are tasked with implementing and carrying these plans and procedures are often left out of security planning processes, creating a fractured relationship between development and security.

This was the conclusion from a VMware and Forrester study of 1,475 IT and security managers, including CIOs and CISOs and managers with responsibility for security strategy and decision-making.

The report found security is still perceived as a barrier in organizations, with 52% of developer respondents saying they believed that security policies are stifling their ability to drive innovation.

Only one in five (22%) developers surveyed said they strongly agree that they understand which security policies they are expected to comply with and more than a quarter (27%) of the developers surveyed are not involved at all in security policy decisions, despite many of these decisions greatly impacting their roles.

The research indicated that security needs a perception shift and should be more deeply embedded across people, processes and technologies.

This means involving developers in security planning earlier and more often; learning to speak the language of the development team rather than asking development to speak security, sharing KPIs and increasing communication to improve relationships and automating security to improve scalability, the report recommended.

Set a Clear Scope for Security Requirements

“Regardless of whether if it’s customer-facing functionality or a business logic concern, every line of code developed should prioritize security as a design feature,” he said. “Once security is taken as seriously as other drivers for DevOps adoption, then a fully holistic integration can be achieved.”

#DevSecOps: A leader’s guide to producing secure software without compromising flow, feedback and continuous improvement

Tags: DevSecOps, Software developer

Sep 24 2021

OWASP Top 10 2021: The most serious web application security risks

Category: App Security,Web Security — DISC @ 9:49 am
OWASP Top 10 2021: The most serious web application security risks

How is the list compiled?

“We get data from organizations that are testing vendors by trade, bug bounty vendors, and organizations that contribute internal testing data. Once we have the data, we load it together and run a fundamental analysis of what CWEs map to risk categories,” the Open Web Application Security Project (OWASP) explains.

“This installment of the Top 10 is more data-driven than ever but not blindly data-driven. We selected eight of the ten categories from contributed data and two categories from the Top 10 community survey at a high level.”

The reason for leaving space for direct input from application security and development experts on the front lines is the fact that it takes time to find ways to test new vulnerabilities, and they can offer knowledge on essential weaknesses that the contributed data may not show yet.

The list is then published so that it can be reviewed by practitioners, who may offer comments and suggestions for improvements.

OWASP Top 10 2021

OWASP Top 10 2021: What has changed in the last 4 years?

Tags: OWASP Top 10

Sep 13 2021

Mobile app creation: Why data privacy and compliance should be at the forefront

Category: App Security,Mobile Security — DISC @ 9:44 am
Mobile app creation: Why data privacy and compliance should be at the forefront

A user’s personal data can be anything from their user name and email address to their telephone name and physical address. Less obvious forms of sensitive data include IP addresses, log data and any information gathered through cookies, as well as users’ biometric data.

Any business whose mobile app collects personal information from users is required to have a Privacy Policy. Regardless of app geography or business domain, there are mandatory regulations such as the GDPR, the CCPA, and the PDPA, as well as Apple, Google and Android guidelines that ensure accountability and user data privacy. Some apps do not directly collect personal data but instead use a third-party tool like Google Analytics – they, too, need a Privacy Policy.

Data privacy and security and the mobile app creation process

Xamarin in Action: Creating native cross-platform mobile apps

Tags: Mobile app

Aug 28 2021

Big bad decryption bug in OpenSSL – but no cause for alarm

Category: App Security — DISC @ 9:29 pm
Big bad decryption bug in OpenSSL – but no cause for alarm

The bugs

OpenSSL, as its name suggests, is mainly used by network software that uses the TLS protocol (transport layer security), formerly known as SSL (secure sockets layer), to protect data in transit.

Although TLS has now replaced SSL, removing a huge number of cryptographic flaws along the way, many of the popular open source programming libraries that support it, such as OpenSSL, LibreSSL and BoringSSL, have kept old-school product names for the sake of familiarity.

Despite having TLS support as its primary aim, OpenSSL also lets you access the lower-level functions on which TLS itself depends, so you can use the libcrypto part of OpenSSL to do standalone encryption, compute file hashes, verify digital signatures and even do arithmetic with numbers that are thousands of digits long.

There are two bugs patched in the new version:

  • CVE-2021-3711
    :     SM2 decryption buffer overflow.
  • CVE-2021-3712
    :     Read buffer overruns processing ASN.1 strings.

Strings, long and short

Network Security with OpenSSL

Tags: OpenSSL

Aug 25 2021

APIs Create New Security Headaches

Category: App Security — DISC @ 10:52 pm
APIs Create New Security Headaches

How APIs Create Security Risks

The proliferation of APIs that power applications, microservices, containers and serverless functions have created one of the greatest sources of security risk that businesses face today. The reason is simple: It’s not the development team’s responsibility to handle security. At the same time, however, security operations teams don’t have visibility into APIs. Because you can’t protect what you can’t see, Lebin Cheng, head of API security, office of the CTO at Imperva, pointed out three primary ways APIs create security risk for organizations:

  • A legacy application, initially deployed for internal use, is exposed externally using gateways that perform only fundamental authentication and authorization, with inadequate protection against sophisticated data exfiltration attempts. Because APIs are often connected directly to a data source, this can give attackers direct access to sensitive data.
  • Modern applications are increasingly built with outsourced components and/or services. This means that the majority of the application stack isn’t actually owned by the enterprise. What connects all these components is the API, but organizations often lack the visibility to monitor these API calls or the ability to secure the APIs in runtime.
  • The speed of software development is the Achilles’ heel of a security team. Developers need to move quickly and publish lines of code and APIs. However, the traditional approach of penetration testing for vulnerabilities isn’t feasible in today’s modern application workflow because it takes too long to conduct. This is creating a tug-of-war internally between the DevOps and SecOps teams.

“Data exfiltration through a compromised or vulnerable API is the risk organizations need to be most worried about,” said Cheng in an email interview. According to research by Imperva Research Labs, the number of new API vulnerabilities grew at the same time other vulnerabilities decreased; by 2024, it’s predicted that API abuses and related data breaches will nearly double in volume.

Enter the Hackers

API Security in Action

Tags: API security risks

Aug 25 2021

How to Reduce Risk with Runtime Application Self Protection

Category: App Security,Information Security — DISC @ 1:03 pm
How to Reduce Risk with Runtime Application Self Protection

Instead of waning, cyber attacks continue to rise as the years pass. Several reasons contribute to this phenomenon, despite developing and deploying more robust network and data security platforms. First, the recent spate of disruptive cyberattacks hampering operations of organizations and government agencies proves that cybercriminals are becoming bolder in perpetuating their malicious activities.

These nefarious actors attack small, medium, and large corporations and organizations. Several attacks were publicized. Most of them are high-profile ransomware victims: Kaseya, JBS, SolarWinds, Colonial Pipeline, Acer, AXA, and CAN Financial. Many of them opted to pay the ransom demand not to disrupt operations that can affect thousands of businesses and consumers.

The nagging question is why cyberattacks are happening more often today. First, attackers are getting more sophisticated. Second, many are organized hacking groups, while some are already identified as government-backed hackers. The increase in cyberattacks can be attributed to several reasons, namely:

  • The willingness of many victims to pay the ransom;
  • Increased use of unregulated cryptocurrencies, which are harder to trace;
  • Publication of cyberattacks enticed other hackers to try the activity themselves, taking the publication of the attacks as successes of cybercriminals– this turned into a get-rich-quick scheme;
  • Increasing numbers of people going online, especially amid the pandemic.

Table of Contents

Alice and Bob Learn Application Security

Tags: Runtime Application

Aug 18 2021

Adopting Zero-Trust for API Security

Category: Access Control,App Security,Zero trust — DISC @ 11:56 am
Adopting Zero-Trust for API Security

Why Use Zero-Trust for API Security

Think of APIs as the new network; interconnected in complex ways and with API interactions happening both within and outside  of the organization.

“Public-facing APIs—for example, consumer banking—are usually a key area of focus when it comes to zero-trust,” said Dunne. “This is due to the obvious risk exposure when APIs are documented and made available on the public internet.”

However, the larger risk is found in private and internal APIs, because there is a common assumption that since they aren’t documented or found on a public network, they aren’t exposed.

But as threat actors become more sophisticated in their search for and discovery of private APIs, there is increased risk of the bad guys gaining access to massive amounts of sensitive data. Private APIs need the same layers of protection as public-facing APIs.

“APIs are, by definition, atomic in nature—meaning they can be invoked independently,” explained Setu Kulkarni, vice president, strategy at NTT Application Security in an email interview. “That creates a real challenge for securing these APIs.”

Given that, Kulkarni added, a critical consideration for implementing zero-trust in APIs is to ensure that there is appropriate access control built into the API implementation. Every API function call requires not just authentication but also authorization. Also, adding zero-trust around session validation helps to prevent unintended data leakage.

Integrating Zero-Trust in APIs

API Security in Action

Tags: API Security

Aug 13 2021

Google open-sourced Allstar tool to secure GitHub repositories

Category: App Security,File Security,Security Tools — DISC @ 10:02 am
Google open-sourced Allstar tool to secure GitHub repositories

Google has open-sourced the Allstar tool that can be used to secure GitHub projects and prevent security misconfigurations.

Google has open-sourced the Allstar tool that can be used to secure GitHub projects by enforcing a set of security policies to prevent misconfiguration.

“Allstar is a GitHub App installed on organizations or repositories to set and enforce security policies. Its goal is to be able to continuously monitor and detect any GitHub setting or repository file contents that may be risky or do not follow security best practices.” reads the project description. “If Allstar finds a repository to be out of compliance, it will take an action such as create an issue or restore security settings.”

Open Source Intelligence Techniques: Resources for Searching and Analyzing Online Information

Tags: Open source

Aug 07 2021

The RedMonk Programming Language Rankings

Category: App Security,Information Security,Security vulnerabilities,Web Security — DISC @ 11:42 am
The RedMonk Programming Language Rankings: June 2021

This iteration of the RedMonk Programming Languages is brought to you by Microsoft. Developers build the future. Microsoft supports you in any language and Java is no exception; we love it. We offer the best Java dev tools, infrastructure, and modern framework support. Modernize your Java development with Microsoft.

While we generally try to have our rankings in July immediately after they are run, we generally operate these on a better late than never basis. On the assumption, then, that August is better than never, below are your RedMonk Q3 language rankings.

As always, these are a continuation of the work originally performed by Drew Conway and John Myles White late in 2010. While the specific means of collection has changed, the basic process remains the same: we extract language rankings from GitHub and Stack Overflow, and combine them for a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction. The idea is not to offer a statistically valid representation of current usage, but rather to correlate language discussion and usage in an effort to extract insights into potential future adoption trends.

Our Current Process

The data source used for the GitHub portion of the analysis is the GitHub Archive. We query languages by pull request in a manner similar to the one GitHub used to assemble the State of the Octoverse. Our query is designed to be as comparable as possible to the previous process.

  • Language is based on the base repository language. While this continues to have the caveats outlined below, it does have the benefit of cohesion with our previous methodology.
  • We exclude forked repos.
  • We use the aggregated history to determine ranking (though based on the table structure changes this can no longer be accomplished via a single query.)

For Stack Overflow, we simply collect the required metrics using their useful data explorer tool.

With that description out of the way, please keep in mind the other usual caveats.

Java Script

Tags: Programming Language

Jul 12 2021

APPSEC TESTING APPROACHES

Category: App Security,Pen Test — DISC @ 1:59 pm

AppSec testing Approach CheatSheet pdf download

5 Things a Pen Tester Looks for When Evaluating an Application

PenTest as a Service

Pentest as a Service Platform

The Web Application Hacker’s Handbook

Tags: #PenTest, AppSec, DevSecOps, PentestasaService

Jun 29 2021

4 Warning Signs of an Insecure App

Category: App Security — DISC @ 10:05 am
4 Warning Signs of an Insecure App

The “golden age of digital transformation” is upon us, and companies around the globe are scurrying to meet consumers on the digital frontier. For developers, it is a virtual gold rush, as businesses overhaul their infrastructure to meet consumers where they are—their mobile phones. For most, this means developing a mobile app.

Unfortunately, the byproduct of the scramble to build a mobile app is that essential features are often overlooked or omitted entirely. There are many things that can be missed when creating an app (like network tolerance and accessibility)–but confoundingly, the feature that’s most often forgotten is the most important: app security.

Data use and privacy are top-of-mind for users. It is vital that software developers don’t cut corners when it comes to securing a mobile app. A secure app should pass the coffee table test: Would I be comfortable going to the bathroom and leaving my phone on a public coffee table?

It’s no secret that app security is a hot topic, but what are the actual warning signs of an insecure app?

Tags: Application security, Insecure App

May 20 2021

Hiring remote software developers: How to spot the cheaters

Category: App Security — DISC @ 10:11 am
Hiring remote software developers: How to spot the cheaters

How are software development applicants cheating?

Prior to COVID-19, many companies had engineering applicants take coding skills assessments in person. On-premises testing allowed employers to control the environment and observe the applicant’s process. Now, employers are providing these assessments (and getting observations) remotely, and applicants (almost exclusively at the junior level) are gaming the platforms.

The two most common strategies are plagiarism and identity misrepresentation. In the former, applicants copy and paste code found on sites like Github or they are lifting code from prior assessments administered by the same employer that have been published and/or sold online. (Companies that have only a few variations of a coding challenge will find, with a quick Google search, that prior test-takers have either posted it online or are offering the answers privately. They’ll even sprinkle in some minor differentiations so that it’s harder to catch.) Identity misrepresentation means asking or paying someone else to log in to the test platform and solve the test (or part of it) for the applicant.

Globally, the rate for plagiarism in 2020 was 5.6%, and suspicious connectivity patterns – indicative of session handover to someone else other than the applicant – appear in 6.48% of sessions. We are seeing a slight growth in the percent of sessions with suspicious behaviors, and this growth is visible in both global and financial markets in particular.

Some industries will have higher rates of cheating than others; for example, organizations in the government, education, and non-profit sectors can see up to double the global average for red-flag behavior. The general shortage of HR professionals with deep technical knowledge make practically all employers vulnerable to inefficiencies and the perils of under-qualified tech candidates making it too far into the recruitment funnel. Higher rates of cheating mean that IT professionals need smarter tools to avoid mis-hires.

Addressing this problem needs to be a priority for employers looking to hire remotely on a larger scale or as a permanent practice, because the short- and long-term consequences are always more costly than whatever investments they put into preventative safeguards.

Hiring a person who cheated in the recruitment process is a recipe for disaster, both for the employer and the employee. Job seekers will typically cheat because they lack the qualifications to pass the recruitment process or, sometimes, just lack the confidence that they can succeed. In either case, if the recruitment leads to employment, the nascent working relationship is botched from day one. The lack of qualifications surfaces sooner or later, frequently damaging schedules, reliability, and security of software products and services, not to mention driving business costs up and reputation down.

More alarmingly, common sense and academic research suggest (Peterson et al., 2011; Schneider & Goffin, 2012), says that the lack of integrity has a potential to reoccur on the job, quite possibly leading to security breaches immensely more dangerous than software bugs. Last but not least, it is plainly emotionally difficult for many individuals to grow a healthy relationship towards the employer and the workplace when the relationship started with dishonesty.

Don't Hire a Software Developer Until You Read this Book: The software survival guide for tech startups & entrepreneurs (from idea, to build, to product launch and everything in between.) by [K.N. Kukoyi]

Tags: DevSecOps

May 16 2021

DevOps didn’t kill WAF, because WAF will never truly die

Category: App Security,next generation firewall — DISC @ 9:21 pm
DevOps didn’t kill WAF, because WAF will never truly die

You can only get rid of WAF if you fully implement security into your development process and audit the process via code reviews and annual tests. But DevSecOps can’t be realistically implemented for all web apps in the enterprise environment, so WAF will stick around because it still has a job to do.

The WAF is not dead, what’s left?

DevOps and the continuous integration and continuous deployment (CI/CD) pipeline provide an excellent opportunity to implement security, especially if your agile methodology includes security sprints. It allows for security to be built into the apps from the start, rather than taking the traditional route of applying it later, which is not only inefficient but – in the frenetic pace of CI/CD – can be overlooked, ignored, or forgotten.

Although security for all web apps should be built-in from the start, our experience shows that it is usually only applied to the “crown jewels,” like the company’s primary customer portal or client payment systems. In an enterprise environment, it’s not unusual for a company to be running old apps in which code is no longer maintained or apps integrated through acquisition.

Additionally, departments such as R&D and marketing frequently implement custom or third-party applications. This app proliferation can result in more than 50% of public-facing web applications in an organization being managed by DevOps or other disparate IT groups. These apps will need additional mitigation controls, which is where WAF comes in.

Tags: DevOps, SecDevOps

Apr 23 2021

Privacy and security in the software designing

Category: App Security,Information Privacy — DISC @ 9:49 pm
Privacy and security in the software designing

The importance of carrying out a careful risk and impact assessment in order to safeguard the security of the information and the data privacy.

In order to reduce as much as possible the vulnerabilities and programming errors that can affect not only the quality of the product itself but can also be exploited to launch increasingly sophisticated and growing computer attacks, it’s necessary to guarantee the protection parameters of computer security in terms of integrity, confidentiality and authentication both for the code of an application and for data management. Therefore, it’s essential to carry out a careful risk and impact assessment in order to safeguard the security of the information and the data privacy.

The project must be planned, following a common denominator for the whole software life cycle, to ensure the security requirements for the data, functions and programming language.

The reference model used in this discussion is, for simplicity’s sake, sequential, in which only after completing one phase does one move on to the next. However, it could be envisaged, for greater efficiency and flexibility, to revise and correct the various phases:

  • requirements study and analysis;
  • designing;
  • implementation and system check;
  • distribution and maintenance.

Apr 23 2021

Outpost24 report finds Top 10 US Credit Unions all have web application issues

Category: App Security,Web Security — DISC @ 9:12 am
Outpost24 report finds Top 10 US Credit Unions all have web application issues

Apr 20 2021

Web Application Security’s Lost Year

Category: App Security,Web Security — DISC @ 1:15 pm
Web Application Security’s Lost Year

Web Application Security More Critical Than Ever

Other findings from the report include:

  • An overall prevalence of high-severity vulnerabilities such as remote code execution, SQL injection, and cross-site scripting;
  • Medium-severity vulnerabilities such as denial-of-service, host header injection and directory listing, remained present in 63% of web apps in 2020;
  • Several high-severity vulnerabilities did not show improvement in 2020 despite being well understood, such as the incidence of remote code execution, which increased by one percentage point last year.

COVID-19 pushed organizations and consumers to an even greater reliance on web applications. As organizations depend on web applications – ranging from web conferencing and collaboration environments to e-commerce sites – to handle what were once in-person tasks, web application security has become even more critical than ever. And that’s what makes a lost year of web application security so troublesome.

Web attacks reached new highs during the pandemic, according to Interpol, and that puts the security of companies at greater risk.

“It’s very troubling to see this loss of momentum due to reduced attention to web application security,” said Invicti president and COO Mark Ralls in a formal statement. “As we look ahead, we hope to see organizations adopt best practices and invest in security, so that they can continue to advance their web security posture, protect their customers, and avoid being the next big security breach headline.”

Apr 20 2021

Digital business requires a security-first mindset

Category: App Security,Information Security — DISC @ 9:01 am
Digital business requires a security-first mindset

Digital business mindset

While developing a seamless and successful digital mindset with a security strategy is not a simple task, the effort is crucial for the health of a company. Unfortunately, security tools haven’t always gotten the best rep with developers, who feared the tools would slow them down, reflect poorly on their work, or even cost them their job if something were to go wrong. For example, static application security tools (SAST) often yield false positives requiring significant resources to remediate.

Since remediation advice is often generic, in some cases, developers wind up spending an extensive amount of time reading through lengthy documentation to understand the right fix. So how can organizations create a security-first culture despite these barriers?

Digital business requires a security-first mindset

Tags: security-first mindset

Apr 05 2021

Securing Dev Environments is Security Leaders’ Top Concern

Category: App Security — DISC @ 12:27 pm
Securing Dev Environments is Security Leaders’ Top Concern

Tags: DevOps, SecDevOps

Apr 03 2021

Applications Are Everything and Everywhere – Does Whack-a-Mole Security Work?

Category: App Security — DISC @ 10:53 pm
Applications Are Everything and Everywhere – Does Whack-a-Mole Security Work?

The SolarWinds digital supply chain attack began by compromising the “heart” of the CI/CD pipeline and successfully changing application code. It highlighted the major challenges organizations face in securing their applications across the software development lifecycle and is driving increased attention at the highest levels of enterprise and government. In fact, Reuters recently reported that the Biden administration is preparing an executive order outlining new software security and breach disclosure requirements.

As organizations look to strengthen their digital supply chain and protect the applications they develop and use, many are focusing on application secrets – which are ripe targets for attackers and can provide unrestricted privileged access to sensitive systems.

Cloud-Native Apps Expand Security Needs

Today, many organizations are taking a cloud-native approach to building, testing and deploying new applications – whether front- or back-office, consumer-facing, web or mobile. And by embracing DevOps methodologies and automation, they’re quickly moving along the digital maturity curve.

As applications are increasingly built using microservices and run in dynamic, short-lived containerized environments, everything needs to interact with each other – sharing secrets and credentials to securely access resources. The result: a lot more secrets that need to be secured.

What’s more, the powerful DevOps and automation tools developers use such as Jenkins and Ansible to build applications store massive amounts of credentials and secrets within them. This allows the projects, playbooks and scripts managed by these mission-critical “Tier 0” assets to access other tools, services and platforms. All of these tools also require high levels of privilege.

« Previous Page — Next Page »