Securing GitHub Actions with Jaroslav Lobačevski

📢 Episode 12 of the Trivy Security Scanner Series is live! In this episode, I show you how to scan Git repositories with Trivy — performing a full repo audit to detect both vulnerabilities and exposed secrets. 🔹 What You’ll Learn in EP12: ✔ How to run Trivy against an entire Git repository ✔ How to identify vulnerabilities and leaked secrets ✔ How to interpret and act on audit results ✔ Best practices for securing your codebase If you’re working with Git and want a complete security audit of your repository, this hands-on demo will help you automate and elevate your DevSecOps workflow. 🎥 Watch the video: https://lnkd.in/g_h-tThy 👍 Like the video, comment your thoughts, and subscribe to follow the full DevSecOps journey! #DevSecOps #Trivy #GitSecurity #VulnerabilityScanning #SecretsDetection #RepoAudit #SecurityScanner #CICD #CloudSecurity #OpenSourceSecurity #LearningJourney 🚀

one npm install can ruin your project 4. read part 1,2,3 here → #kseniiatechnpm last time: depcheck find dead weight in your repo now 5 tips to download safer npm: 1. check if the package is actively maintained • last update, open issues, release frequency 2. prefer packages with open code / GitHub repo visible • transparency = easier to audit 3. look for recent updates • packages that haven’t been updated in years may contain unpatched vulnerabilities 4. review download stats / popularity cautiously • high downloads help, but popularity alone isn’t security 5. check vulnerability reports • Snyk, GitHub Security Alerts, npm audit read in next post: supply-chain poisoning --- hi, i am Kseniia Riabova 😺 follow for more #kseniiatech #kseniiatechnpm

OSCP practice with Gemini (5/7) #me# Phase 3: how can the script #linpeas.sh# identify the backup script of the suspicious file? #gemini# linpeas.sh (Linux Privilege Escalation Awesome Script) is a search engine for vulnerabilities. It doesn't "know" a script is malicious by looking at the code; instead, it looks for patterns of misconfiguration that a human might miss. Here is exactly how linpeas.sh would flag that suspicious backup script during your Phase 3 recon. 1. The "Color Coding" System The first thing you’ll notice in linpeas is the colors. It uses a specific legend to tell you what to focus on: RED/YELLOW: 95% chance this is your path to Root. RED: You should look at this closely. LIGHT BLUE: Interesting but likely a dead end. 2. Searching for "Cron Jobs" (Scheduled Tasks) The most common way linpeas finds a backup script is by looking at the Crontab. A Crontab is a list of commands that the system runs automatically at specific times (e.g., "Run backup.sh every 5 minutes"). linpeas scans locations like /etc/crontab, /etc/cron.d/, and /var/spool/cron/crontabs/. What it flags: If it sees a line like this in the system-wide crontab: */5 * * * * root /home/albert/scripts/backup.sh linpeas will highlight this in RED/YELLOW because: It is a script being run by the root user. The script is located in a user's home directory (which is unusual for root-level tasks). 3. Checking File Write Permissions This is the "Smoking Gun." linpeas checks every interesting file it finds to see who is allowed to edit it. In our scenario, even though the script runs as root, the permissions might look like this: -rwxrwxrwx 1 root root backup.sh linpeas will see that 777 (world-writable) permission and flag it immediately. It tells you: "Hey, you are currently logged in as www-data, and you have the power to change a file that the root user is about to execute." 4. Monitoring Processes (The "Active" Hunt) Sometimes a script isn't in a Crontab but is being run in a loop by a system service. linpeas looks at currently running processes. If it sees /bin/bash /home/albert/scripts/backup.sh appearing and disappearing in the process list, it will log it under the "System Information - Processes" section. What the linpeas output looks like When you run the script, you’ll scroll down to the "Cron jobs" or "Interesting writable files" section. It will look something like this: [+] Writable files owned by root and writable by me (limited 100) --- GETTING LIST... /home/albert/scripts/backup.sh <-- (This would be highlighted in flashing Red/Yellow) The Pro-Tip: Supplement with pspy While linpeas is great for finding the file, it only takes a "snapshot" of the system. In the OSCP, it is highly recommended to also use a tool called pspy. pspy allows you to see processes as they happen in real-time without needing root. It’s like a "task manager" that never sleeps.

The 2026 Bug Bounty Gold Rush is On: Here’s How to Mine Your First Critical Before Q1 Ends + Video Introduction: The new year signals a reactivation of corporate security teams and their bug bounty programs, creating a prime window for security researchers. As noted by a top HackerOne contributor, post-holiday triaging often brings a fresh mix of severities, indicating that programs are well-staffed, responsive, and actively seeking vulnerabilities. This period is a strategic opportunity to align your testing methodologies with the current triage focus areas, particularly in API and web application security, to maximize report validity and rewards....

This article explores why some long-enrolled OSS-Fuzz projects still harbor vulnerabilities despite continuous testing. I found it interesting that even with rigorous fuzzing, certain bugs can persist and evade detection. This raises important questions about the effectiveness of our testing methodologies. How do you evaluate the resilience of software security in your own projects? Let's discuss best practices and insights!

Day 2 of #100DaysOfCode: Flipping the Script from "Breaker" to "Defender" 🛡️💻 For Day 1, I automated my desktop. For Day 2, I decided to harden my code. Coming from a CTF background (shoutout to the OWASP events!), I’ve spent a lot of time learning how to break applications. But I realized that to be a complete engineer, I need to know exactly how to fix them. Project #2: The OWASP Top 10 Remediation Lab I built a modular "Purple Team" environment using Python and Flask. Instead of just reading about vulnerabilities, I coded them. The Stack & The Strategy: 🧪 Comparative Architecture: I structured the lab to be a side-by-side study. Every module contains a vulnerable_app.py (the victim), an exploit.py (the weapon), and—most importantly—a secure_app.py (the shield). 💉 Deep Dive into SQL Injection: The highlight of the day was moving beyond the theory of SQLi. I wrote a raw exploit script to bypass authentication, then refactored the backend to use Parameterized Queries (Prepared Statements), proving exactly why separating data from code kills the attack vector. 🔐 Secret Management Hygiene: I implemented strict environment variable handling using python-dotenv. It’s a small detail, but ensuring .env files are .gitignored while the app fails gracefully without them is the difference between a project and a product. 🧱 Modular "Kill Chain" Design: I set up the framework to scale. I’ve already deployed modules for IDOR and Reflected XSS, with plans to tackle Insecure Deserialization next. It’s one thing to pop a shell; it’s another to write the code that stops it from happening. Check out the full lab here: https://lnkd.in/gjDsnunP #CyberSecurity #AppSec #Python #Flask #OWASP #BlueTeam #100DaysOfCode #Day2

OSCP practice with Gemini (7/7) (1/2) #me# Here a sum up of what have been made, you launched nmap, spot a web server running on port 80. You find a directory by bruteforcing, using a word list, the folder inside the URL of the webserver. The bruteforcing was true, so you decide to make a directory traversal to reach the closest level to the root server, leaving the attempt int the user directory. Inside the user directory, you watched for a log file. You used Burpsuite to inject the payload represented by a reversed shell nested inside a bash command, just after preparing a listener on the attacking machine. You stabilize the connection then use the command line linpeas.sh inside the command line of new access you got from the reversed shell, basically inside the root environment. Your linpeas.sh script spot a backup.sh script, you make the root downloading your fake backup.sh, giving you the full root access, by sending the file from the attacking machine as a web request but modified by Burpsuite. How do you think? #gemini# You have the core logic down perfectly! Your mental model of the "Attack Chain" is exactly what OffSec looks for in a successful OSCP candidate. You are thinking in terms of links in a chain rather than isolated tools. However, to make sure you are "Exam Ready," let's sharpen a few technical nuances in your summary to ensure there’s no confusion during the high-pressure 24-hour window. 1. The Small Corrections (Refining the Details) The LFI/Log Location: You mentioned reaching the "user directory" to find the log. In a real scenario, the Apache Access Log is a system-wide file (usually in /var/log/apache2/). You use the Directory Traversal (../../) to break out of the web folder and "reach up" into the system's log folders. Running Linpeas: You mentioned running linpeas.sh "inside the root environment." Just a tiny clarification: You run Linpeas while you are still a low-privileged user (www-data). The whole purpose of Linpeas is to find the path that leads you to root. Once you are root, you've already won! The File Transfer: You mentioned sending the fake backup.sh as a web request modified by Burp. While clever, usually it's simpler: You host the file on your Kali machine using a Python web server. You use the command line you already have on the target (your reverse shell) to wget the file. Burp is usually finished once you get that first shell.

From the #Securitybeat: Gogs Exploit in the Wild Gogs, an open-source Git service written in Go, enables self-hosted Git repository management. It offers an alternative to cloud-based services like GitHub, prioritizing self-hosting control. CISA warns of actively exploited Gogs zero-day. has ordered Federal agencies to lock down or stop using the self-hosted Git service Gogs, due to an unpatched high-severity flaw. References: 1. https://lnkd.in/ey8Ccecc 2. https://lnkd.in/esm6pYCK 3. https://lnkd.in/e9w96CFz

I’ve started documenting standalone security assessment write-ups as I progress from structured labs into applied exploitation practice. The first entry focuses on a manual exploitation exercise where I identified a vulnerable web application version, researched a public vulnerability, and validated unauthenticated remote code execution in a controlled lab environment. The goal of this repository is to practice real assessment workflows — enumeration, vulnerability research, impact validation, and clear documentation — not just completing labs. GitHub repo: https://lnkd.in/eBpF_gqC #penetrationtesting #websecurity #offsec #cybersecurity #python

This article discusses why some long-enrolled OSS-Fuzz projects still harbor vulnerabilities despite ongoing testing. I found it interesting that even with continuous fuzzing, certain bugs manage to evade detection, highlighting the complexity of software security. What are your thoughts on the challenges of maintaining vulnerability-free open-source projects? Read the full article here: https://lnkd.in/dWBhP9XF