Back

Explore every episode of the podcast CyberSecurity & DevSecOps Expert: Develop, PenTest, and Deploy Secure Applications

Dive into the complete episode list for CyberSecurity & DevSecOps Expert: Develop, PenTest, and Deploy Secure Applications. Each episode is cataloged with detailed descriptions, making it easy to find and explore specific topics. Keep track of all episodes from your favorite podcast and never miss a moment of insightful content.

Rows per page:

1–50 of 199

TitlePub. DateDuration
Red thread 2 — Model and document the threats of a Weather API23 sept. 202600:15:00
## Context You are hired as a junior security analyst for a startup that publishes a public REST **Weather API**. This API exposes endpoints such as `GET /weather?city=`, `GET /forecast?lat=&lon=`, `POST /users` (registration), `POST /login` (authent...
Model documentation and versioning best practices23 sept. 202600:15:00
Threat modeling is only useful if the results are captured, shared, and kept up to date. A threat model that lives in someone's head or in an outdated diagram provides no value to the team. This chapter explains how to document a threat model properl...
Tools for modeling threats — Threat Dragon, Draw.io, others23 sept. 202600:15:00
Threat modeling is only as effective as the tools you use to draw, document, and share it. Up to now, you have learned the concepts: confidentiality, integrity and availability (the CIA triad), the STRIDE categories, attack surface analysis, security...
Getting started with OWASP Threat Dragon on the Blog project23 sept. 202600:15:00
THEORETICAL RECAP Threat modeling is the structured practice of identifying, communicating, and understanding threats and mitigations within the context of protecting an application. OWASP Threat Dragon is a free, open-source tool that lets you draw ...
Case study — Transforming a STRIDE threat into an automated test scenario22 sept. 202600:15:00
This case study connects everything you have already studied: the STRIDE threat categories, the attack surface, the security principles, the OWASP Risk Rating methodology, the correction and testing heuristics, and the security checklist. The goal he...
Adapting the checklist to a third party public API22 sept. 202600:15:00
THEORETICAL RECAP A security test checklist derived from a threat model is not a fixed artifact: it must be adapted to the specific context of the target. A third-party public API differs sharply from an internal service. Key definitions: a 'third-pa...
From modeling to test plans — a practical and practical bridge22 sept. 202600:15:00
So far, you have learned to identify an attack surface, to apply security principles, to model threats with STRIDE, and to prioritize risks using the OWASP Risk Rating Methodology. All of this is analytical work. But analysis alone changes nothing ab...
Develop a test checklist based on the threat model22 sept. 202600:15:00
THEORETICAL RECAP A threat model is a structured description of what can go wrong in an application: assets to protect, entry points (attack surface), threats (typically classified via STRIDE: Spoofing, Tampering, Repudiation, Information disclosure,...
Visual summary — Mental map of the concepts seen21 sept. 202600:15:00
This chapter closes the section on Application Security Principles and Threat Modeling. Its purpose is not to introduce new material, but to assemble everything you have studied into a single coherent mental map. A mental map is a way of representing...
Varying the scoring on an e-commerce API21 sept. 202600:15:00
THEORETICAL RECAP Risk scoring turns a vague sense of danger into a comparable number so you can prioritize corrections and tests. The OWASP Risk Rating Methodology models Risk = Likelihood x Impact. Likelihood is estimated from Threat Agent factors ...
Heuristics to prioritize corrections and tests18 sept. 202600:15:00
In the previous activities, you learned to identify the attack surface of an application, to map threats using the STRIDE model, to apply secure design principles, and to score threats with the OWASP Risk Rating Methodology (probability versus impact...
Score previous threats with OWASP Risk Rating18 sept. 202600:15:00
THEORETICAL RECAP The OWASP Risk Rating Methodology estimates the severity of a threat by combining two dimensions: Likelihood (how probable an attack is) and Impact (the damage it causes). Each dimension is broken into factors scored from 0 to 9. Li...
OWASP Risk Rating Methodology — probability vs impact17 sept. 202600:15:00
In the previous activities, you built a threat matrix for the Blog, mapped its attack surface, and applied secure design principles such as Least Privilege and Defense in Depth. You also practiced classifying threats with STRIDE. Now that you can ide...
Map the Blog's attack surface16 sept. 202600:15:00
THEORETICAL RECAP The attack surface is the sum of all points where an unauthorized actor can attempt to enter, extract, or manipulate data within a system. It includes entry points (HTTP endpoints, forms, APIs, file uploads, cookies, headers), data ...
Attack surface — definition and identification15 sept. 202600:15:00
The attack surface is one of the most important concepts in application security and threat modeling. Now that you have practiced drawing Data Flow Diagrams, applying the STRIDE methodology, building threat matrices, and evaluating applications again...
Adapting the principles to a file upload microservice15 sept. 202600:15:00
THEORETICAL RECAP Secure design principles are not abstract rules; they are decision filters you apply to concrete features. Least Privilege means every component (service account, container, database user, storage bucket) holds only the permissions ...
Case study — Incident due to the absence of Least Privilege14 sept. 202600:15:00
In the previous activities, you learned to model threats with STRIDE, to draw Data Flow Diagrams, to build a threat matrix, and to evaluate an application against secure design principles such as Least Privilege and Defense in Depth. This case study ...
Evaluate the Blog against the principles of secure design11 sept. 202600:15:00
THEORETICAL RECAP Secure design principles are foundational rules that guide how an application should be architected to minimize attack surface and contain damage when a component is compromised. The core principles you must know include: Least Priv...
Secure Design Principles — Least Privilege & Defense in Depth11 sept. 202600:15:00
In the previous activities, you learned to identify threats using the STRIDE method, to draw Data Flow Diagrams, and to build a complete threat matrix for a Blog application. Those activities focused on finding and classifying threats. This activity ...
Red thread — Building a complete threat matrix for the Blog10 sept. 202600:15:00
## Project Overview This mini-project is the culmination of the 'Application Security Principles and Threat Modeling' chapter. You will consolidate everything you have practiced so far — components/assets identification, CIA, STRIDE, Data Flow Diagra...
Identify STRIDE threats in the DFD10 sept. 202600:15:00
THEORETICAL RECAP Threat modeling connects two artifacts you have already built: the Data Flow Diagram (DFD) and the STRIDE taxonomy. A DFD represents your application as external entities (users, third parties), processes (services, APIs), data stor...
Draw the DFD for the Blog application09 sept. 202600:15:00
THEORETICAL RECAP A Data Flow Diagram (DFD) is a graphical model that shows how data moves through an application. It relies on four core symbols: external entities (rectangles) representing actors or systems outside your control (users, third-party ...
Data Flow Diagram (DFD) — symbols and best practices09 sept. 202600:15:00
A Data Flow Diagram, often abbreviated as DFD, is a visual representation of how information moves through an application or a system. In threat modeling, it is the foundation on which everything else is built. Before you can apply STRIDE, identify a...
STRIDE on a “create post” API endpoint08 sept. 202600:15:00
THEORETICAL RECAP STRIDE is a threat modeling framework that classifies threats into six categories: Spoofing (impersonating an identity), Tampering (altering data or code), Repudiation (denying an action without traceability), Information Disclosure...
Apply STRIDE on the authentication flow07 sept. 202600:15:00
THEORETICAL RECAP STRIDE is a threat classification model created by Microsoft that maps six threat categories to the security properties they violate: Spoofing (breaks Authentication), Tampering (breaks Integrity), Repudiation (breaks Non-repudiatio...
STRIDE method — description and examples04 sept. 202600:15:00
The STRIDE method is a structured approach to threat modeling. It was developed at Microsoft to help teams systematically identify the ways an application or system can be attacked. You have already studied why we model threats, how to break an appli...
Break down the simplified Blog application into components03 sept. 202600:15:00
THEORETICAL RECAP Threat modeling always starts with understanding what you are protecting. Before you can identify threats, you must decompose the application into its components. A component is any distinct part of the system that stores, processes...
Why model threats? Benefits and key steps03 sept. 202600:15:00
Threat modeling is a structured way of thinking about what can go wrong with an application before attackers find out for you. In the previous activities, you learned about assets (things worth protecting), the Confidentiality, Integrity and Availabi...
Associate risk scenarios with OWASP Top 10 (maps)01 sept. 202600:15:00
THEORETICAL RECAP The OWASP Top 10 is a consensus-based, regularly updated list of the ten most critical web application security risks. It is not a checklist of individual bugs but a set of risk categories, each grouping many concrete weaknesses. Th...
Light introduction to OWASP Top 10 (risk vision)01 sept. 202600:15:00
The OWASP Top 10 is a reference document published by the Open Worldwide Application Security Project, a nonprofit foundation dedicated to improving software security. This document lists the ten most critical security risks for web applications. It ...
Classify CIA impacts on Todo List assets31 août 202600:15:00
THEORETICAL RECAP The CIA triad describes three security properties every asset can require: Confidentiality (only authorized parties can read the data), Integrity (data cannot be altered or destroyed without authorization or detection), and Availabi...
Actor vs Attacker — clarifying roles31 août 202600:15:00
In the previous activities you learned the essential vocabulary of security — asset, threat, vulnerability, risk — and you explored the three foundational properties of information security: Confidentiality, Integrity, and Availability. You also prac...
Confidentiality, Integrity, Availability (CIA) — foundations28 août 202600:15:00
In the previous activities, you learned the essential vocabulary of security: asset, threat, vulnerability, and risk. You also practiced locating assets inside a simple application such as a Todo List. Now we build on that foundation with the single ...
Locate assets in a “Todo List” application27 août 202600:15:00
THEORETICAL RECAP In threat modeling, an 'asset' is anything of value that an attacker might want to steal, alter, destroy, or misuse — and that you must therefore protect. Assets are not only files or databases; they include data (user credentials, ...
Essential vocabulary — active, threat, vulnerability, risk26 août 202600:15:00
Welcome to the first true building block of application security. Before you can defend an application, run a penetration test, or set up a secure delivery pipeline, you must master a small set of words used every single day by security professionals...
Welcome and chapter goals26 août 202600:15:00
Welcome to the chapter on Application Security Principles and Threat Modeling. This chapter is the foundation of the entire training path that will turn you into a CyberSecurity and DevSecOps professional. Before you learn how to attack applications,...
Conclusion, resources and next steps25 août 202600:15:00
This chapter closes the module dedicated to advanced Linux for security. You have travelled a long way: from user and group management, sudoer configuration, and the creation of restricted accounts, to writing executable scripts scheduled with cron, ...
Apply a hardening checklist on VM labo24 août 202600:15:00
## Project Overview In this mini-project, you will apply a complete security hardening checklist to a Linux virtual machine (VM) in a lab environment. This project consolidates every skill covered in the 'Linux advanced for security' chapter: user an...
Hardening principles: CIS Benchmarks & minimization24 août 202600:15:00
Hardening a Linux system means reducing its attack surface and configuring it so that it resists attacks as much as possible. Until now you have written scripts, managed users and sudoers, configured logging, and audited authentication logs. Hardenin...
Scan /var/log/auth.log for detections21 août 202600:15:00
THEORETICAL RECAP On Debian-based Linux systems, /var/log/auth.log records authentication and authorization events: SSH connections (successful and failed), sudo invocations, su attempts, PAM messages, and session open/close events. On RHEL-based sys...
Logging & auditing: syslog, journald, logrotate20 août 202600:15:00
Logging and auditing are the backbone of security operations on a Linux system. Logs are the recorded traces of what happens on a machine: services starting and stopping, users logging in, commands executed with elevated privileges, failed authentica...
Create a restricted pentest user19 août 202600:15:00
THEORETICAL RECAP On Linux, every process runs with the privileges of a user and its groups. The principle of least privilege dictates that an account should hold only the permissions strictly required for its tasks—nothing more. A pentester frequent...
Advanced user and sudoer management19 août 202600:15:00
Advanced user and sudoer management is a cornerstone of Linux security. On a Linux system, every process and every file is tied to an identity. Understanding how users, groups, and privilege elevation work allows you to reduce the attack surface, app...
Make it executable and schedule via cron18 août 202600:15:00
THEORETICAL RECAP A Bash script is just a text file until you grant it execute permission and provide an interpreter. The shebang line (#!/bin/bash) on the first line tells the system which interpreter to use. Permissions are managed with chmod: chmo...
Best practices & pitfalls in scripting17 août 202600:15:00
Scripting is one of the most powerful tools a security professional has. A well-written Bash or Python script can automate reconnaissance, parse thousands of log lines, back up critical files, or orchestrate a deployment. But a poorly written script ...
Write a /etc backup script17 août 202600:15:00
THEORETICAL RECAP The /etc directory is the heart of Linux system configuration. It contains critical files: user accounts (/etc/passwd, /etc/shadow), network settings, service configurations, firewall rules, and repository definitions you manipulate...
Bash scripting: variables, loops, conditions14 août 202600:15:00
Bash (Bourne Again Shell) is the default command interpreter on most Linux distributions. Writing scripts in Bash allows you to automate repetitive tasks, chain together the network and system tools you have already studied (ip, ss, nmap, apt, system...
Third-party security updates and repositories13 août 202600:15:00
On a Linux system, software is installed and updated through package managers such as apt (Debian, Ubuntu) or yum/dnf (Red Hat, CentOS, Fedora). These package managers download software from repositories. A repository is a server that hosts packages ...
Install nmap and wireshark13 août 202600:15:00
THEORETICAL RECAP Before any penetration test or network analysis, you need a reconnaissance toolkit. Two tools are foundational: nmap and Wireshark. Nmap (Network Mapper) is an active scanner: it sends crafted packets to hosts to discover live machi...
Package management: apt, yum/dnf12 août 202600:15:00
Package management is one of the most important skills for anyone administering or securing a Linux system. A package is a compressed archive that contains a program, its libraries, configuration files, and metadata describing what the software needs...
© My Podcast Data · Independent project · Data from Apple & Spotify