If you’ve ever tried digging through Windows event logs, you already know the pain — thousands of entries, confusing structures, and XML data that can make your head spin. Now imagine doing that for dozens or hundreds of systems during an investigation. That’s where EvtxECmd , created by Eric Zimmerman , becomes a real lifesaver. At first glance, EvtxECmd looks like another command-line tool that converts .evtx files into CSV, XML, or JSON formats. But once you start using it, you realize it’s much more than that. It’s a smart, flexible event log parser that helps you extract the right information instead of drowning in all the noise. Why Windows Event Logs Are Tricky Windows event logs are incredibly detailed — sometimes too  detailed. Each event type (like a logon or a process creation) stores information differently. There’s no single consistent structure, which makes it difficult to normalize or compare data across systems. Let’s take Event ID 4624 (a successful logon) as an example. One event might store the username in a particular XML field, another event might bury it in a nested tag. Multiply that inconsistency across hundreds of event IDs, and you quickly see why filtering event logs manually is a nightmare. How EvtxECmd Solves This Problem EvtxECmd fixes this inconsistency by using something called Map files . Think of Map files as small “blueprints” that tell the tool exactly what to extract from each event type. These Maps are crowd-sourced , meaning the community contributes templates for different event types, and each map uses XPath filters  to pull out only the relevant details — usernames, IP addresses, domains, process names, etc. For example: For Event ID 4624, it might extract the TargetUserName  and TargetDomainName . For Event ID 4688, it might extract the command line , parent process , or executable path . Once extracted, EvtxECmd organizes all this information into clean columns in a CSV file. You can now easily filter, search, or group the data without wrestling with XML. It’s like turning chaos into a spreadsheet of clarity. Working Smarter with PayloadData Columns You’ll notice that the tool uses columns named PayloadData1–6 . These are general-purpose slots that can hold different kinds of data depending on the event type. Why not just have separate columns for everything? Because that would result in hundreds  of columns — way too messy. So instead, EvtxECmd lets every event type reuse these six slots for its most important details. That means in one row, PayloadData1 might be a username, and in another, it might be a process name. To know what each means, you can simply refer back to the event’s ID and the corresponding Map file. Once you understand this logic, analyzing large sets of logs becomes surprisingly straightforward. Bringing It All Together with Timeline Explorer Parsing logs is just half the battle — the real magic happens when you start analyzing .Eric Zimmerman’s Timeline Explorer  pairs perfectly with EvtxECmd output. You can open the CSV file in Timeline Explorer and use features like: Filtering by keyword or event ID Grouping by columns  (for example, EventID, Username, LogonType) Counting event occurrences Quick sorting and drilling down Here’s a simple example: If you group by EventID, UserName, and LogonType, you can instantly see how many times each user logged example via RDP (LogonType 10) . You might discover that a user who normally logs in locally suddenly had two RDP sessions from an unknown IP — a quick red flag for possible lateral movement. Scaling It for Real Investigations EvtxECmd isn’t limited to just one system. You can run it on: Live systems  to extract and filter logs on the fly Mounted disk images  or triage collections  during incident response Even older versions of logs through the Volume Shadow Service (VSS) It can also de-duplicate events  across multiple sources, which is super helpful when you’re merging logs from dozens of endpoints. This scalability is what makes it a go-to tool for forensic analysts and threat hunters. Whether you’re investigating a ransomware infection or tracking a suspicious user account, EvtxECmd helps you see patterns that would otherwise stay hidden. unning EvtxEcmd on live system to extract artifacts: COMMAND LINE:  -     EvtxECmd.exe -d C:\windows\system32\winevt\logs --csv C:\Users\user\desktop --csvf eventlogs.csv –vss Breaking Up: -d (directory)  (Path of (directory)logs where it present) --csv \Users\user\desktop (CSV Format where you want store) --csvf eventlogs.csv File name to save CSV formatted results   –vss  Process all Volume Shadow Copies that exist on drive Running EvtxEcmd on collected logs from system: COMMAND LINE:  -     EvtxECmd.exe -d C:\users\user\downloads\logs\ --csv C:\Users\user\desktop --csvf eventlogs.csv -d (Provide path where all logs present)               Running EvtxEcmd on Single log for example security.evtx: COMMAND LINE:  -     EvtxECmd.exe -f C:\users\user\download\security.evtx --csv C:\Users\user\desktop --csvf eventlogs.csv -f (For single evtx file) ------------------------------------------------------------------------------------------------------------- Final Thoughts EvtxECmd takes something notoriously messy — Windows event logs — and turns it into structured, searchable data. It bridges the gap between raw XML chaos and actionable insight. If you’re new to log analysis, this tool will help you focus on what matters: the story the events are trying to tell. And if you’re an experienced investigator, EvtxECmd’s flexibility and map-based approach can dramatically speed up your workflow. -------------------------------------------------------Dean-------------------------------------

Hey everyone Let’s talk about one of the most underrated but dangerous  parts of automation and DevOps: secrets management . You might not realize it, but every single system you build — whether it’s an app, CI/CD pipeline, or cloud deployment — has secrets . These are things like API tokens, SSH keys, database passwords, and service credentials that your automation tools, containers, and scripts need to function. ------------------------------------------------------------------------------------------------------------- Why Secrets Management Matters In modern DevOps and cloud environments, everything is automated — provisioning, configuration, deployment, and release pipelines. But automation often requires privileged access to services. That means your infrastructure and code are constantly touching credentials and tokens. So if secrets are hardcoded, exposed in version control, or shared in plain text… well, you’re basically leaving your passwords under the doormat. 🫣 ------------------------------------------------------------------------------------------------------------- How Not  to Keep Secrets Let’s start with what not to do  — because this is where many developers slip up. Keeping Secrets in Code A lot of people hardcode secrets right into their code because it’s quick and easy. But that’s a huge security risk. Why? Anyone with access to your repository can read those secrets. Even if you delete the secret later, it still lives in your version history . In Git, everyone  has a full copy of the repo — including that secret. Rotating secrets means you have to redeploy the code every time. Bottom line: never hardcode credentials . Ever. ------------------------------------------------------------------------------------------------------------- Be Especially Careful with GitHub GitHub is an amazing place for collaboration — but it’s also a goldmine for attackers searching for exposed secrets. Tools to Scan for Secrets in Git Repos Here are some great open-source tools that can help you detect secrets in your repositories: Gitrob 👉 https://github.com/michenriksen/gitrob Scan GitHub repos for sensitive files, credentials, and even things like IPs, domains, and tokens. It maps out all repos under your organization and flags risky content. truffleHog 👉 https://github.com/dxa4481/truffleHog Performs deep searches through the entire commit history  of a repo, looking for high-entropy strings (which often indicate secrets). Git-all-secrets 👉 https://github.com/anshumanbh/git-all-secrets Clones and scans repos using multiple tools (including truffleHog). A great “all-in-one” option. These tools help you catch exposed secrets before they catch you . ------------------------------------------------------------------------------------------------------------- Preventing Secrets from Getting Into Code Detecting secrets is one thing — but wouldn’t it be better if they never made it  into your codebase in the first place? That’s where pre-commit tools come in. They stop you from accidentally committing secrets to your repo. Here are some popular ones: git-secrets  (by AWS Labs) 👉 https://github.com/awslabs/git-secrets Blocks commits that contain secrets. It can be installed locally and even customized with regex patterns. Talisman (ThoughtWorks) 👉 https://github.com/thoughtworks/talisman Hooks into Git’s pre-push process and scans for suspicious content — like private keys or tokens — before allowing a push. SEDATED (OWASP) 👉 https://github.com/OWASP/SEDATED Prevents sensitive data from being pushed to remote Git servers. Git Hound 👉 https://github.com/ezekg/git-hound Uses regular expressions to detect sensitive data in commits and blocks the push if something looks fishy. You can also check out the Pre-commit framework , which has a plugin called detect-secrets  — easy to integrate with your workflow. ------------------------------------------------------------------------------------------------------------- Hands-on with Git-Secrets Let’s look at how to actually use git-secrets , since it’s one of the most popular tools out there. Step 1: Install git-secrets Inside your Git repo, run: git secrets --install This sets up pre-commit hooks automatically. You should see: ✓ Installed commit-msg hook ✓ Installed pre-commit hook ✓ Installed prepare-commit-msg hook Step 2: Register AWS patterns (optional) If you’re using AWS credentials: git secrets --register-aws Step 3: Check what patterns are active git secrets --list This lists all the regex patterns it’s scanning for — like AWS access keys or secret keys. Step 4: Scan your repo git secrets --scan If nothing shows up — awesome! It means your repo is clean. 🎉 ------------------------------------------------------------------------------------------------------------- Ansible — Keep It Simple, Keep It Safe Ansible Vault  ( official docs ) is built right into Ansible (since version 1.5). It allows you to encrypt sensitive data (like passwords, private keys, and tokens) inside special files called vault files . These can be safely stored in your Git repo or shared between teams — no more plain-text secrets! To use it: ansible-vault create secrets.yml You can then edit, view, or decrypt files with: ansible-vault edit secrets.yml ansible-vault view secrets.yml ------------------------------------------------------------------------------------------------------------- Secret Keepers — Centralized Secrets Management At some point, you’ll realize: instead of juggling secrets across multiple tools, you need a central place  to store, rotate, and control access. That’s where Secret Keepers  or Secrets Servers  come in. These are dedicated platforms that: Store and encrypt secrets centrally Allow secure API or CLI access Support rotation, revocation, and auditing Manage authentication and access policies Provide high availability and logging Open-Source Secret Keepers Tool Description Vault OSS (HashiCorp) The most widely used open-source secrets manager. Supports dynamic secrets, key rotation, encryption as a service, and integrates with multiple backends (AWS, databases, etc.). Conjur OSS (CyberArk) Open-source enterprise-grade secrets and identity manager. Handles access control and secret retrieval. Keywhiz (Square) Provides secure access to secrets via REST API or FUSE filesystem. Uses mTLS for authentication. Confidant (Lyft) AWS-native secrets manager that stores encrypted data in DynamoDB. Knox (Pinterest) Lightweight, developer-friendly secrets tool written in Go for key creation and rotation. Commercial Secrets Management Tools Tool Description Amazon KMS Manages encryption keys using dedicated hardware security modules (HSMs). Fully integrated with AWS services. Amazon Secrets Manager Manages secrets like API keys and DB credentials with APIs for rotation and retrieval. CyberArk Secrets Manager Enterprise-grade vaulting solution with AD/LDAP integration and strong auditing. Google KMS / Secret Manager Scalable key and secret management for Google Cloud Platform. Integrated with IAM and audit logging. Microsoft Azure Key Vault Protects keys and secrets using FIPS 140-2 certified HSMs. Integrates with Azure logging and identity services. Vault Enterprise (HashiCorp) Commercial version of Vault with advanced identity management, MFA, replication, and enterprise support. ------------------------------------------------------------------------------------------------------------- Wrapping It Up Secrets management is one of those things that’s boring until it’s not . One small mistake — a single exposed API key — can lead to massive data breaches or unauthorized access. So, remember: Never hardcode secrets. Scan your repos regularly. Use pre-commit hooks  to stop leaks before they happen. Automate responsibly. Your code should be powerful — but your secrets should stay silent . -------------------------------------------------Dean-------------------------------------------------------

When we talk about secure coding , we usually think about the code we  write — avoiding insecure functions, preventing injections, or following secure design patterns. But here’s the truth: most of the code running in production today wasn’t even written by us. That’s not necessarily bad — open source drives innovation and saves time. But it also means that we’re inheriting someone else’s vulnerabilities , and in many cases… we don’t even realize it. ------------------------------------------------------------------------------------------------------------- The Open-Source Dependency Problem Here’s the scary part: A single outdated dependency can silently introduce critical security vulnerabilities into your entire application stack. Let’s say you build a web app that depends on 10 libraries. Those libraries might depend on 50 others. And if even one of them has a known vulnerability your system might be at risk without you even touching a line of insecure code. The problem grows when: Developers download old or vulnerable packages  from package managers. Teams don’t update  to newer, patched versions. And sometimes, no one even knows what dependencies  are in the system. That’s why organizations now use dependency analysis tools  — also known as Software Composition Analysis (SCA)  — to automatically detect and monitor these risks. ------------------------------------------------------------------------------------------------------------- How Dependency Scanning Works Dependency analysis tools scan your project’s: Source code Manifest files  (like package.json, requirements.txt, or pom.xml) Or even compiled build artifacts They then identify every open-source component and compare them against known vulnerability databases  — such as the National Vulnerability Database (NVD)  or other proprietary sources. If a component version matches a known vulnerable one, you’ll get an alert — often with details about the CVE ID , severity , and recommended fix . Modern CI/CD pipelines can even fail a build automatically  if a critical vulnerability is detected, preventing risky code from being deployed. ------------------------------------------------------------------------------------------------------------- Popular Open-Source Tools for Managing Vulnerable Dependencies Several open-source tools can help detect and manage vulnerable libraries across different programming ecosystems. Here are some of the most widely used: Tool Language / Features OWASP Dependency-Check Scans Java, .NET, Ruby, Node.js, Python, and limited C/C++ (autoconf/cmake). Compares against CVE databases. Bundler-Audit Checks Ruby Gem dependencies for known vulnerabilities. Retire.js Scans JavaScript libraries (including browser JS) for known security issues. PHP Dependency Checker Detects insecure PHP Composer dependencies. GitHub Dependabot Alerts Automatically detects and reports vulnerable dependencies in Java, JavaScript, .NET, PHP, Python, and Ruby projects. Safety Checks Python dependencies against the Safety DB. Microsoft Application Inspector CLI tool that analyzes dependencies, highlights risks, and flags potential backdoors. Open-source tools include: Ruby:   Bundler-Audit Node.js:   Node Security Project (NSP) JavaScript:   Retire.js PHP:   PHP Dependency Checker Python:   Safety ------------------------------------------------------------------------------------------------------------- Commercial Tools for Dependency Management If you’re working in an enterprise environment, there are several commercial SCA tools  that go beyond open-source scanners. These tools typically: Offer deep integration  into CI/CD pipelines Include license compliance checking Maintain proprietary vulnerability databases  for faster detection Provide governance controls  for managing third-party risk Here are some leading solutions: Tool Features Black Duck (Synopsys) Inventories open-source code for both security and license vulnerabilities. FOSSA Multi-language component analysis with license governance. Sonatype Nexus Lifecycle Integrates into CI/CD pipelines; checks for vulnerable or non-compliant components. Snyk Finds and patches vulnerabilities in Node.js, Ruby, Python, Java, Scala, and more. Free for open-source projects. FlexNet Code Insight Manages and controls downloads of open-source components. SourceClear (CA/Veracode) Detects vulnerabilities not yet public using proprietary analysis. WhiteSource (now Mend) Plugin-based solution that checks both security and licensing issues. JFrog Xray Works with Artifactory; performs deep dependency and license scanning. WhiteHat Security (Sentinel SCA) Adds software composition analysis into the Sentinel Source platform. ------------------------------------------------------------------------------------------------------------- Why This Matters Modern development depends heavily on open-source software — and that’s perfectly fine as long as we manage it responsibly . A single vulnerable dependency can compromise your entire product. That’s why integrating SCA tools (like OWASP Dependency-Check or Snyk) into your CI/CD pipeline  is now considered a best practice. When configured properly, these tools will: Identify outdated or risky components Provide clear remediation paths Automate version updates Help enforce open-source license compliance In short, they give you visibility and control — two things that are often missing when dealing with complex dependency chains. ------------------------------------------------------------------------------------------------------------- Final Thoughts Insecure dependencies are one of the biggest blind spots in modern software development. You might be following every secure coding guideline out there, but if your application uses a vulnerable third-party library, you’re still exposed. By combining SAST tools like Semgrep  with SCA tools like Dependency-Check or Snyk , you get a complete view of your codebase — both your own code and what you’ve inherited. This layered approach is key to building truly secure applications. -------------------------------------------------Dean-------------------------------------------------

Whenever I talk about incident response or large-scale data collection, one feature that never fails to amaze me is how PowerShell handles remote execution . It’s built right into Windows, it’s fast, secure, and surprisingly flexible. And trust me — once you understand how powerful remote execution can be, tools like Kansa start to make a lot more sense. Let’s start with the basics. PowerShell Remoting – The Foundation for Scalable Response One of the most useful features of PowerShell is its native support for running commands on remote systems. That’s exactly what makes PowerShell such a gem for incident responders. It uses Windows Remote Management (WinRM) , which in turn relies on WS-Management (WSMAN)  — a protocol that runs over HTTP/S and uses SOAP and XML for communication. If you’ve ever used Enter-PSSession you already know how easy it is to jump into an interactive remote shell. And unlike RDP or PSExec, PowerShell doesn’t leave your credentials lying around on the remote system . That’s a huge win for security. But the real magic happens when you use Invoke-Command With this cmdlet, you can push commands or even entire scripts to one or multiple remote systems — simultaneously. No loops, no complexity. Just one command, and you’re executing across potentially hundreds or even thousands of machines. You might think, “Alright, but won’t that take forever?” Actually, no., WMI loop across 100 systems took six hours, while Invoke-Command did it in just 15 seconds. When scaled up to 1,000 systems, it will finish in just over two minutes. That’s the level of efficiency PowerShell brings to the table. So why am I talking so much about PowerShell remoting? Because that’s exactly what powers Kansa , one of the most beautifully simple yet powerful tools I’ve ever used in my incident response toolkit. ----------------------------------------------------------------------------------------------------------- Let’s Talk About Kansa Now, I’ll be honest — Kansa  isn’t actively maintained by Dave Hull anymore. But even without updates, it’s still one of the most solid, reliable PowerShell-based IR frameworks out there . If you ask me personally, I’d say I prefer KAPE  for many use cases, especially for its modular speed and portability. But when I first saw how simple and effective Kansa  is, I couldn’t help but dive into it. What Makes Kansa Awesome Kansa leverages PowerShell Remoting to run user-defined modules across multiple systems. Whether you’re performing an incident response, threat hunt, or building an environmental baseline — Kansa’s got you covered. Here’s what it does under the hood: If you don’t give it a list of targets, it’ll automatically query Domain Controllers  to find systems. It manages errors and logs  everything neatly to a central file. It runs modules in parallel , up to 32 systems at a time by default. It organizes the output beautifully — one file per host per module. And it uses a Modules.conf  file where you decide which scripts to run and in what order. That last point is really smart. The configuration follows the Order of Volatility , meaning it prioritizes collecting fast-changing data like DNS cache, ARP tables, or Prefetch information first, before moving on to less volatile artifacts. You just move the module names up or down in the file to control the order. Kansa was built for scale — you can gather data from hundreds (or even thousands) of hosts at once, as long as two things are true: WinRM is enabled on your targets, and You’ve got local admin access. That’s it. No fancy setup, no third-party dependencies. ------------------------------------------------------------------------------------------------------------- Setting Up and Using Kansa Getting started is simple — you just grab it from GitHub ( https://github.com/davehull/Kansa ) and extract it anywhere you like. Inside the repository, you’ll find: A Modules  folder — this is where the data collection scripts live, grouped by type. An Analysis  folder — which contains PowerShell scripts for post-collection analysis. If you plan to use the analysis scripts, make sure to drop logparser.exe into your system path (it’s not included by default) . The good part is — Kansa’s output is tab-separated text , so you can load it into Excel, a database, or even feed it into Logparser for custom queries. And here’s what makes it even better: You don’t have to run the full suite  — each of Kansa’s PowerShell scripts can be executed separately. This flexibility means you can use it like a mini collection toolkit. Run just what you need, when you need it.' Honestly, some of the Kansa scripts are among the best-written PowerShell scripts  I’ve seen in the IR space. They’re clean, modular, and incredibly easy to adapt. --------------------------------------------------------------------------------------------------------- Getting Started with Kansa A simple command to kick off data collection using Kansa looks like this: PS C:\tools\Kansa> .\kansa.ps1 -TargetList .\hostlist -Pushbin Here’s what each parameter means: -TargetList .\hostlist  → Specifies the list of systems you want to collect data from. The file should contain one host per line. If you omit this parameter, Kansa automatically queries Active Directory  for all systems. To use AD querying, make sure the Remote Server Administration Tools (RSAT)  module is installed. You can also limit the scope using -TargetCount  to test with a smaller subset before scaling up. -Pushbin  → Tells Kansa to push any required third-party binaries to the target systems before running the collection scripts. Understanding the Kansa Folder Structure Kansa’s folder structure is simple and modular: Kansa │ ├── kansa.ps1 # Main launcher script ├── Modules # Contains PowerShell collectors │ ├── bin # Third-party binaries │ ├── Get-Autorunsc.ps1 │ ├── Get-CertStore.ps1 │ └── ... └── Output # Collection results (auto-created) All collection results are saved in the Output  folder. Each module’s results are written into its own subfolder, and most modules output data in TSV (Tab-Separated Values)  format, making it easy to parse and analyze. Adding Third-Party Binaries While PowerShell is powerful, some modules depend on third-party tools. Kansa supports this through a simple mechanism called a binary dependency directive . For example, the Get-Autorunsc.ps1  module includes the following line: # BINDEP .\Modules\bin\Autorunsc.exe This line tells Kansa to copy Autorunsc.exe to the target machine before running the script. The binaries are copied by default to %SystemRoot% (usually C:\Windows). If you want Kansa to clean up after itself , use the -Rmbin argument to remove these binaries once collection completes. Some modules that rely on third-party binaries include: Get-Autorunsc.ps1 Get-CertStore.ps1 Get-FlsBodyfile.ps1 Get-Handle.ps1 Get-ProcDump.ps1 Get-RekalPslist.ps1 Kansa at Enterprise Scale Originally, Kansa was designed for small to mid-scale collections (150 systems or fewer at a time). However, in 2020, Jon Ketchum transformed it into a truly enterprise-scale tool capable of handling data collection across 150,000+ systems . Why Kansa Matters Kansa bridges the gap between manual data collection  and enterprise-grade visibility . It allows responders to: Gather forensic artifacts quickly from multiple endpoints. Integrate PowerShell and third-party tools into a single workflow. Scale investigations without complex infrastructure. Whether you're running an investigation on 10 systems or 10,000, Kansa adapts to your operational tempo. Real Talk: The Trade-offs Of course, like any live response framework, Kansa isn’t immune to being tricked by rootkits. Since it relies on Windows APIs (just like WMI, .NET, or system commands), a well-built rootkit could theoretically hide its presence . But in the real world, that’s rare. You’re trading off a bit of forensic depth for speed and scale , and that’s usually worth it when you’re dealing with hundreds of endpoints. You can always follow up with a deep dive on a smaller set of systems once you’ve used Kansa to get the bigger picture. Conclusion Kansa remains one of the most underrated tools in incident response. It combines the flexibility of PowerShell with the structure of a modular framework — perfect for both rapid triage and deep forensic collection. If you’re building your own IR toolkit, Kansa deserves a top spot on your list.

If you’ve ever worked on secure coding or DevSecOps pipelines, you’ve probably come across the term SAST  — Static Application Security Testing. These are the tools that scan your source code for vulnerabilities, misconfigurations, or insecure patterns before  your application even runs. One of the most popular and lightweight tools in this space is Semgrep  — a static analysis tool that’s fast, open-source, and surprisingly easy to customize. Let’s talk about what makes Semgrep stand out and why it’s becoming a go-to for developers and security engineers. -------------------------------------------------------------------------------------------------------- What is Semgrep? Semgrep is an open-source static analysis engine   It’s designed to analyze source code across multiple programming languages, helping you find potential vulnerabilities or risky code patterns. Unlike many bulky enterprise scanners, Semgrep is: Lightweight  – It’s easy to set up and run locally or in CI/CD pipelines. Extensible  – You can easily write your own custom rules. Multi-language  – It supports a wide variety of languages, including: Go, Java, JavaScript, Python, Ruby, TypeScript, C#, and even markup formats like JSON and YAML. That’s pretty rare for an open-source static analysis tool. -------------------------------------------------------------------------------------------------------- How Semgrep Works Semgrep doesn’t just perform simple text searches like grep. Instead, it parses your code into Abstract Syntax Trees (ASTs)  — which basically means it understands  the structure of your code. This allows Semgrep to detect complex issues with a high level of accuracy. Semgrep’s scanning logic is powered by rules , which are written in YAML format. These rules describe specific code patterns or behaviors you want to find. The cool part? You can easily write, test, and publish your own rules using the Semgrep Playground . -------------------------------------------------------------------------------------------------------- The Semgrep Registry If you don’t want to start from scratch, the Semgrep Registry  has you covered. It’s a large community-driven collection of over 1,000 rules , all publicly available at semgrep.dev/explore . Some of the most popular rulesets maintained by r2c are: r2c-ci  – Focused on high-confidence, low-noise rules for CI/CD pipelines. r2c-security-audit  – A more in-depth security audit ruleset for catching subtle vulnerabilities. You can think of these like plug-and-play templates that help you quickly integrate security scanning into your workflow. -------------------------------------------------------------------------------------------------------- Running Semgrep from the Command Line Running a Semgrep scan is incredibly simple. Once you’ve installed it (via CLI or Docker), you can run a full security audit of your codebase with just one command: semgrep --config "p/r2c-security-audit" This command downloads and runs over 200 security-focused rules from the Semgrep registry against your code. By default, results are printed directly to your terminal (stdout). -------------------------------------------------------------------------------------------------------- Semgrep Command-Line Options If you want to customize your scans, Semgrep’s CLI gives you several options. Here are the most useful ones: Option Description -f or -c Specify a YAML configuration file, folder of rule files, or a ruleset from the registry -e Run a custom search pattern directly from the command line -l Restrict scanning to a single language -o Save results to a file or send them to a remote endpoint You can explore all options by running: semgrep --help -------------------------------------------------------------------------------------------------------- Writing Custom Rules One of Semgrep’s biggest strengths is how easy it is to write custom detection rules . You can do this using the Semgrep Playground  ( semgrep.dev/editor ), which lets you test your rules interactively. For example, let’s say you want to identify any AWS policy file that gives full S3 access (s3:*). Here’s a simple rule written in YAML: rules: - id: s3_wildcard_permissions pattern: | { "Effect": "Allow", "Action": "s3:*" } message: Semgrep found a match severity: WARNING This rule will flag any JSON configuration file where Action: "s3:*" appears — a sign of an overly permissive IAM policy. What’s amazing here is that the same rule syntax can be used to scan source code, cloud configs, or even Kubernetes YAML files . So, whether you’re a developer or a cloud engineer, you can use one tool and one query language to identify risky patterns across your entire DevOps pipeline. -------------------------------------------------------------------------------------------------------- CI/CD Integration Semgrep was designed with automation in mind. It fits seamlessly into CI/CD pipelines using: CLI commands Docker containers GitHub Actions This makes it perfect for embedding into your build pipelines , so you can automatically catch vulnerabilities before code is merged — without slowing down developers. -------------------------------------------------------------------------------------------------------- Final Thoughts Semgrep is a great example of how open-source security tools  can compete with — and often outperform — commercial solutions. It’s fast, flexible, and transparent, giving you the power to scan code in your own way. Whether you’re a security engineer trying to enforce secure coding standards or a developer looking to clean up risky code, Semgrep is a tool worth adding to your toolkit. If you want to try it out, here are the official resources: 🔗 GitHub: returntocorp/semgrep 🌐 Semgrep Registry 🧰 Semgrep Playground --------------------------------------------Dean----------------------------------------------------

Configuration code and application code both need to be treated with the same rigor as any other software. Bugs in configuration can be especially dangerous because they can create operational outages, scalability issues, or security vulnerabilities at scale . Unfortunately, reviewing this code often requires specialized knowledge of the underlying platforms and tools, which makes mistakes easier to miss. This is where static analysis  comes in. Static analysis tools help detect common errors, enforce best practices, and highlight potential security issues—before they impact production. Static Analysis for Configuration Management Chef RuboCop  – Ruby style and code quality checks. Cookstyle  – Chef’s official linting tool, powered by RuboCop. Foodcritic (Sunsetted 2019)  – legacy tool, no longer maintained. Puppet Puppet-lint  – syntax and style checks. puppet-lint-security-plugins  – additional security rules. Puppeteer  – automated testing for Puppet code. Ansible Ansible-lint  – ensures playbooks follow best practices. KICS  – infrastructure-as-code security scanner. AWS CloudFormation cfn_nag  – scans templates for insecure patterns. cfripper  – evaluates IAM and security risks. cfn-python-lint  – syntax validation. CloudFormation Guard  – policy-as-code validation. Checkov  – scans IaC for misconfigurations. Static Analysis for Application Code Java Code Quality & Bugs : FindBugs (legacy) , SpotBugs , PMD , Checkstyle . Security : Find Security Bugs , fb-contrib . Advanced Analysis : Error Prone (Google) , Infer (Meta) , SonarSource . .NET / C# FxCop  – legacy, built into Visual Studio. StyleCop  – style enforcement. Puma Scan  – security plugin. Security Code Scan  – Roslyn-based security checks. Roslynator  – analyzers & refactorings. SonarSource . JavaScript Style & Quality : ESLint , JSHint , JSLint . Security : NodeJsScan . Others : Closure Compiler , Flow , SonarSource . PHP Phan  + Taint Check Plugin . PHP CodeSniffer , PHP Mess Detector . Progpilot , Exakat . RIPS (commercial) , SonarSource . Ruby Brakeman  (security), Dawnscanner . RuboCop , RubyCritic . Railroader , SonarSource . Python Bandit , Dlint . Pylint , Pytype . Pyre , Pyright . SonarSource . C / C++ Cppcheck , Clang Analyzer , OCLint . Flawfinder , Infer , SonarSource . Objective-C / Swift Xcode Analyze . SwiftLint , OCLint . Infer , Faux Pas , SonarSource . Android Android Lint , Qark . Custom Lint Rules . Infer . Go Vet , Lint . errcheck , dingo-hunter . Gosec , SafeSQL . SonarSource . Multi-Language Static Analysis For teams working across multiple languages and frameworks: GitHub CodeQL  – semantic code analysis. Semgrep  – fast, rule-based multi-language scanner. Best Practices for Using Static Analysis Integrate Early  – run lightweight checks in CI/CD pipelines to catch issues before deployment. Balance Depth & Speed  – use incremental scans during commits, and schedule deep scans out-of-band. Triage Findings  – security teams should filter false positives and prioritize high-confidence issues. Automate Feedback  – push findings directly into developer workflows (IDE plugins, backlog tickets). Combine Tools  – no single tool covers everything; use a combination for better coverage. Conclusion Static analysis is not just about checking code quality—it’s about catching vulnerabilities early, reducing technical debt, and preventing misconfigurations from becoming large-scale risks . With the right mix of tools and practices, development and security teams can collaborate more effectively, building software that is both reliable and secure. ---------------------------------------------Dean----------------------------------------------------

When a developer pushes code, it kicks off the Commit phase  of the DevOps pipeline. This is where the magic of automation happens: builds, tests, scans, and packaging all before the code goes anywhere near production. But here’s the trick: we need to build security into this phase —without slowing developers down. What Security Checks Fit Here? Think of the Commit phase as speed security . We don’t have hours; we have minutes. So our checks need to be lightweight but effective: Unit Tests  → Catch coding mistakes immediately. Incremental SAST (Static Analysis Security Testing)  → Scan only the code that changed. Lightweight Linting & Style Checks  → Make code easier to review and maintain. If all tests pass, we sign the build and store it in a secure artifact repository . This guarantees that what gets deployed later hasn’t been tampered with. -------------------------------------------------------------------------------------------------------- The Goal of SAST in CI/CD Here’s the important mindset shift: Traditional SAST  tries to find all  the vulnerabilities in the codebase. That’s slow and overwhelming. Modern SAST in CI/CD  focuses on catching new vulnerabilities introduced by the latest changes . This way, developers get feedback right away and can fix issues before moving on. -------------------------------------------------------------------------------------------------------- Deep vs. Incremental Scanning Not all scans are created equal: Full scans  → Take hours or even days. Perfect for scheduled jobs (nightly, weekly). Incremental scans  → Only look at the code that changed. Perfect for CI/CD, fast feedback in a few minutes. -------------------------------------------------------------------------------------------------------- Tuning Scanners: Take the Hit for the Team Static analyzers are notorious for false positives . If every scan blocks developers with noise, the pipeline will get ignored—or worse, bypassed. That’s why the security team must “take the false positive hit.” Tune scanners to focus on high-risk, high-confidence findings . Store configuration in version control  so changes are audited. Work with engineers to agree on what’s important enough to block the pipeline. Pro tip: Fail the pipeline if any critical/high findings show up. Save the low-confidence stuff for deeper out-of-band scans. -------------------------------------------------------------------------------------------------------- Writing Your Own Checkers Sometimes tools don’t catch everything. That’s where custom checkers  come in: Simple: grep for dangerous functions or hardcoded secrets. Advanced: write custom plugins for SAST tools like PMD or SonarQube. Examples: Flag eval() or exec() in Python. Detect insecure crypto functions (like MD5, SHA-1). Catch hardcoded AWS keys or passwords. -------------------------------------------------------------------------------------------------------- Different Tools, Different Strengths Not all static analysis tools are equal. Here’s a cheat sheet: Coding style tools  → Checkstyle, PMD, StyleCop, ESLint Not security-focused, but make code easier to read and review. Bug pattern detectors  → FindBugs, FxCop Improve reliability and catch some security issues. Security-focused scanners  → Find Security Bugs, Puma Scan, Fortify, SonarQube Security Rules Look for vulnerabilities using data flow, control flow, and taint analysis. Important: There’s very little overlap between these tools. If you want good coverage, you’ll probably need more than one scanner . To handle duplicates across multiple tools, use aggregators like: OWASP Defect Dojo ThreadFix Code Dx -------------------------------------------------------------------------------------------------------- How to Fit This into CI/CD Here’s a practical Commit phase workflow: Developer pushes code → CI kicks in. Unit tests  + lint checks  run in parallel. Incremental SAST scan  runs in parallel. If time limit breached, send an alert + break scans into smaller chunks. If all checks pass → build is signed & pushed to artifact repo. If critical issues found → block the pipeline until fixed. Meanwhile, schedule nightly full scans  with all checkers enabled. The security team reviews those results, filters out noise, and creates tickets for real issues. -------------------------------------------------------------------------------------------------------- The Bigger Picture Security in the Commit phase isn’t about finding everything . It’s about: Catching mistakes early Giving fast, actionable feedback Building security into the team’s Definition of Done ---------------------------------------------Dean--------------------------------------------------

Every codebase has certain files that you just don’t want anyone to casually edit. Think about: Authentication and login logic Password handling and crypto libraries Admin panels and backend controls Code that touches private user data Deployment scripts and pipelines If these pieces of code are changed without proper review, the result could be security vulnerabilities, downtime, or even a data breach . That’s why we need a system to detect high-risk code changes and enforce extra approvals. This is where Code Owners files, custom alerts, and pull request templates  come into play. What are Code Owners? A Code Owners file  is a simple text file you place in the root of your repository. It tells GitHub, GitLab, or Bitbucket who “owns” which parts of the code. Think of it like a digital lock: If someone changes a sensitive file, the lock requires approval from the person or group listed as the code owner. Without approval, the change can’t be merged. Rules that appear later override earlier ones. For example: All developers can edit code by default. But if someone touches AccountController.cs, the security team must approve it. Even the   Code Owners file itself is protected (because changing it could bypass the whole system). Why This Matters Let’s say a junior developer accidentally modifies a password hashing function. Without code owners, the change might slip through with just a casual peer review. With code owners, the security team must approve  it before it gets merged. This gives you: Control  – High-risk code can’t be changed by mistake. Visibility  – Security teams see changes that matter. Accountability  – The right people approve sensitive updates. Detecting Risky Code Changes with Alerts One of the security teams took this a step further. Instead of only depending on code owners, they hash sensitive files  and write unit tests to ensure nothing changes silently. Here’s a C# example: [Theory] [InlineData("/Web/AccountController.cs", "2aabf33b66ddb07787f882ceed0718826af897q7")] [InlineData("/Shared/Services/Cryptography/Hash.cs", "87f88d137d37a7ed908737552eed0c524133b6")] public void HighRiskCode_ChecksumTest(string file, string checksum) { bool match = checksum.Equals(Hash.GetChecksum(file)); if(!match) NotificationService.RequestCodeReview(file); Assert.True(match); } What this does: Each high-risk file has a checksum (unique fingerprint). If the file changes, the test fails. When it fails, the system notifies the developer, their manager, and the security team. This runs automatically in Continuous Integration (CI) . So if someone modifies crypto code, you’ll know immediately. Security Checklists with Pull Request Templates What about developer awareness? That’s where pull request templates  come in. A template is just a Markdown file that gets pre-filled when someone opens a pull request. For example: ### Security Checklist - [ ] Have I reviewed this change for security risks? - [ ] Am I touching authentication, crypto, or private data? - [ ] Have I notified the security team if needed? Developers must check these boxes before submitting. It’s not automatic enforcement, but it creates awareness and accountability . Separation of Duties in Approvals The final piece of the puzzle is workflow separation : Developer opens a pull request. Code owners are automatically assigned. Security team (or other owners) review the changes. Once approved, the merge triggers build pipelines and deployments. This ensures no single person can sneak in a risky change. Approvals must come from the right group of people. ------------------------------------------------------------------------------------------------------------ Putting It All Together This combination gives you: Prevention (owners block unapproved changes)0 -- CODEOWNERS   Detection (unit tests catch file modifications) -- Add checksum-based unit tests   Awareness (checklists guide developers) -- Leverage templates   Governance (audit trail of approvals) -- Require approvals By combining these, you create a secure GitFlow workflow  where high-risk code is guarded, reviewed, and deployed with confidence.

Branches in Git are like “lanes” of code. Some lanes are safe for experiments (feature branches), but others are critical highways (main, develop, release branches). If someone pushes bad code straight into main, it could break production in seconds. That’s why branch protections  exist: to put guardrails around your most important branches. ------------------------------------------------------------------------------------------------------------- GitHub Branch Protections On GitHub, branch protections are very customizable . Here are the most important options: Require Pull Request Reviews (✅ Always Enable) At least 1–2 people must review before merging. Stops “lone wolf” coding straight into production. Include Administrators (✅ Enable this!) By default, admins can bypass protections. If their account or SSH key is compromised, attackers can push directly into main. Enabling this forces even admins to follow the rules. Require Signed Commits (Optional, but Strong) Developers must sign commits with GPG keys. Prevents impersonation or “mystery commits” from unverified users. Disallow Force Pushes (✅ Keep Disabled) Prevents someone from overwriting history with git push --force. Protects from lost work or sneaky backdoor commits. Disallow Deletions (✅ Keep Disabled) No one should be able to delete main or develop. Period. In short:  On GitHub, always enforce reviews, admin restrictions, no force pushes, no deletions . Signed commits are a bonus layer. ------------------------------------------------------------------------------------------------------------- GitLab Branch Protections GitLab’s rules are simpler but still powerful: Allowed to Merge: Decide which group(s) can merge changes. Typically: “Maintainers” for main, “Developers” for develop. Allowed to Push: Should always be set to No One  for protected branches. This forces Merge Requests only , which means reviews and checks must pass. Require Code Owner Approval (Premium Feature): Lets you require approvals from the owner of a specific file or directory . Example: Only security engineers can approve changes to auth/. Great for granular control, but requires GitLab Premium. In short:  In GitLab, enforce No direct pushes, only MRs, proper role-based merging, and (if available) CodeOwner approvals. ------------------------------------------------------------------------------------------------------------- Azure DevOps Branch Policies Azure DevOps calls them Branch Policies , and they’re pretty flexible: Require Minimum Number of Reviewers: Define how many approvals are needed before merge. Typically 2 reviewers for critical branches. Disallow Self-Approval: Prevents developers from approving their own PRs. Helps enforce “separation of duties.” Block Last Pusher from Approving: The person who made the last commit can’t count as a reviewer. Stops someone from sneaking in changes and approving themselves. Reject if Any Reviewer Votes No: Default: if someone rejects, the PR is blocked. You can override this, but generally safer to block unless explicitly approved. Reset Votes on New Commits: If new code is pushed after a review, approvals reset. Ensures fresh eyes on fresh changes. In short:  Azure DevOps gives you more knobs to tune — use them to enforce real reviews, prevent self-approvals, and reset approvals if new code is added. ------------------------------------------------------------------------------------------------------------- Comparing GitHub vs GitLab vs Azure DevOps Feature GitHub GitLab Azure DevOps Require Reviews ✅ Yes ✅ Yes (via MRs) ✅ Yes Admin Restrictions ✅ Yes ❌ Limited ✅ Yes Signed Commits ✅ Yes ❌ Not built-in ✅ Yes (via policy) Force Push Protection ✅ Yes ✅ Yes ✅ Yes Branch Deletion Protection ✅ Yes ✅ Yes ✅ Yes Code Owner Rules ✅ Yes ✅ Premium only ✅ Yes Advanced Review Rules ⚠️ Basic ⚠️ Limited ✅ Very Flexible ------------------------------------------------------------------------------------------------------------- Best Practices (No Matter the Platform) Protect main and develop (and release branches if used). No direct pushes — all changes via PR/MR . Always require at least 1–2 reviewers , preferably more for sensitive code. Don’t let devs approve their own changes. Restrict admins — they should follow the same rules. Disable force pushes and deletions on critical branches. Use Code Owners  for sensitive areas (auth, payments, infra). Branch protections = “guardrails” for your repo .They don’t just enforce process, they reduce insider threats, mistakes, and even admin account compromises . ---------------------------------------------------Dean---------------------------------------------------

When we talk about security in DevSecOps, a lot of risks start right in the repo  before code ever hits CI/CD pipelines. This is where Git commit hooks, pre-commit frameworks, and branch protections come into play. ------------------------------------------------------------------------------------------------------ Git Hooks – Security’s First Gate Think of Git hooks  like little security guards that live inside your Git repository. They’re scripts that run when certain Git events happen (like committing, pushing, or merging code). Local hooks (on developer’s machine): pre-commit: Runs before the commit is made . Perfect spot to check for secrets or run linters. commit-msg: Ensures the commit message follows your org’s rules (e.g., must have a Jira ID). post-commit: Runs right after a commit . Useful for notifications/logging. Server-side hooks (on remote repo): pre-receive: Runs before changes are accepted on the remote repo. Stops bad commits at the gate. update / post-receive: Good for enforcing team policies or kicking off workflows. Why it matters:  Hooks let you catch issues early  (like hardcoded AWS keys, unsafe configs, bad commit messages) before they ever hit CI/CD. ------------------------------------------------------------------------------------------------------ Pre-Commit Frameworks Yes, you could  write your own Git hook scripts, but that’s messy. Instead, teams often use frameworks that manage hooks across multiple languages and repos. Two popular ones: Yelp’s Pre-Commit : You create a .pre-commit-config.yaml in your repo. Add rules (e.g., check for YAML syntax errors, remove trailing spaces, scan for secrets). Every developer who clones the repo gets the same hooks. Overcommit : Another Git hook manager with built-in checks. Widely used in security-focused teams. Example (.pre-commit-config.yaml): repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v2.0.1 hooks: - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace - repo: https://github.com/psf/black rev: 24.3.0 hooks: - id: black With this: Every commit will check if your YAML is valid. Remove trailing spaces automatically. Format Python code using Black. Run pre-commit install once, and boom — your repo now has built-in security and quality checks before anyone can commit bad code. ------------------------------------------------------------------------------------------------------ Peer Code Reviews Automated checks are great, but nothing beats human eyes . That’s where code reviews  come in. Big companies never  let code go straight into production without review. Why? Transparency  – At least one other person knows what’s being changed. Accountability  – Developers are more careful if they know someone else will review their work. Security  – Reviewers can spot “code smells” like: Hardcoded passwords/API keys Custom (and unsafe) cryptography Suspicious or obfuscated logic Incorrect handling of sensitive data Pro tip: Create a security checklist  for reviewers (data validation, error handling, proper logging, etc.). Make high-risk code (auth, payments, encryption, APIs)  require senior or security-team review. Randomly assign reviewers to reduce risks of collusion. ------------------------------------------------------------------------------------------------------ Branch Protections (Your Repo’s Guardrails) Even with hooks and reviews, you don’t want people pushing code directly into main or develop. This is where branch protections  come in. All major platforms (GitHub, GitLab, Azure DevOps, Bitbucket) support this. What branch protections do: ❌ Prevent deleting critical branches (like main). ❌ Prevent direct pushes to release branches. ✅ Require pull/merge requests  for changes. ✅ Force code reviews/approvals before merging. ✅ Allow you to define who  can approve changes (e.g., security must approve auth changes). Example: On GitHub, you can require that: At least 2 reviewers  approve before merge. All checks (tests, scans, pre-commit) must pass. No one can merge unless those conditions are met. This ensures security isn’t optional — it’s baked into the workflow . ------------------------------------------------------------------------------------------------------ Putting It All Together Even if one layer misses something, the others catch it. ✅ Hooks = automatic checks ✅ Pre-commit frameworks = easy setup ✅ Peer reviews = human judgment ✅ Branch protections = safety nets Together, they make your repo a security-first environment .

Hey everyone 👋 So here’s the deal: I’m not a DevOps engineer. I come from the Incident response/Forensic side. But in my current organization, we’re working on DevSecOps , and that means I had to start learning how security fits into the DevOps world. I thought, instead of keeping all this in my notes, why not share it here? I’m trying to simplify things as much as possible. If you find mistakes or think I should add something, just let me know. This is a journey, and I’m still learning too. Where Does Security Fit in DevSecOps? When we talk about DevOps pipelines (Continuous Integration and Continuous Delivery), security can’t just be an afterthought. We have to weave it into every stage. CI (Continuous Integration):  Fast cycle, quick checks. Mostly useful for catching small mistakes like hardcoded passwords, dangerous functions, or dependency issues. Think of it as your “first line of defense.” CD (Continuous Delivery):  This is where the deeper stuff happens—like scanning, penetration testing, and verifying that everything is safe before going live. Bottom line: CI is for quick wins  in security, while CD is for serious checks . Step 1: Pre-Commit (Before the Code Even Lands) This is the stage where developers are still writing or committing code. From a security perspective, this is where we want to stop problems before  they even enter the repo. Here’s what to focus on: Data classification:  Figure out which data is sensitive (personal info, passwords, financial data, etc.). Different data types need different protection levels. Platform risks:  Choosing a cloud, OS, database, or framework? Each has its own security risks. Understand them before locking in your choice. Tool support:  Make sure your toolchain supports security scans (SAST, DAST, IAST). 💡 Tip:  Treat this stage like a health check . If something feels risky—new API, new user role, new database—it’s worth reviewing from a security lens. Quick Threat Modeling (Don’t Panic, It’s Simple) “Threat modeling” might sound heavy, but think of it like asking common-sense questions: Did we just change the attack surface (e.g., opened a new port, exposed an API)? Did we add/upgrade any major library or framework? Are we touching sensitive areas like authentication, encryption, or access control? Are we handling new sensitive data? Are we touching critical or high-risk code? If the answer is yes  to any of these, slow down and do a deeper review. Tools That Can Help (So You’re Not Doing This Alone) Good news: you don’t have to do everything manually. There are plenty of tools and plugins that can catch security issues right as developers are coding. Here are some handy ones: VS Code Plugins: Semgrep  – smart code scanning Checkov  – IaC (Infrastructure as Code) scanning cfn_nag  – scans AWS CloudFormation IntelliJ / Eclipse Plugins: Built-in code inspections (Java, etc.) FindBugs / SpotBugs  – bug detection Find Security Bugs  – security-focused checks For .NET / Visual Studio: Puma Scan Security Code Scan Microsoft DevSkim Commercial Options (if your org wants premium tools): Checkmarx Coverity Fortify Veracode Greenlight Think of these as “spell checkers for code security.” They highlight issues in real time while developers type or when they hit save. ------------------------------------------------------------------------------------------------------------- Example: Spotting Risks in a Repo Let’s say you scan your repo with a tool like SCC (Sloc Cloc and Code) , and it tells you that the main language being used is Dockerfile. As a security person, that’s an “aha” moment. Why? Because Docker means containers, and containers bring their own security challenges—like image scanning, Dockerfile best practices, and proper configuration. So just by knowing the tech stack, you already know what security areas to focus on. ------------------------------------------------------------------------------------------------------------- Wrapping It Up The main point is this: Security in DevOps doesn’t have to be scary or complex. Start small: Catch issues early with pre-commit checks and IDE plugins. Ask simple threat-modeling questions whenever something major changes. Use the right tools to automate scanning so developers get feedback fast. By doing this, security becomes part of the normal workflow—not a blocker at the end. ---------------------------------------------Dean------------------------------------------------------ Keep following and keep checking my best — we will proceed further in the next article.

When installing or running new software, your operating system’s security configuration can change behind the scenes — new services, registry keys, ports, or even accounts might get added. Tracking all of that manually is nearly impossible. That’s where Attack Surface Analyzer (ASA)  comes in. It’s a Microsoft tool that helps you capture and compare snapshots of your system’s state so you can see what changed before and after an installation. Super handy if you want to harden your system or just understand what software is really doing. ------------------------------------------------------------------------------------------------------------- Installing Attack Surface Analyzer Since ASA is built on .NET Core , we first need the .NET SDK : dotnet --version If you don’t have it, grab it from the .NET SDK download page . Step 1 – Install ASA via .NET CLI Once you’ve got .NET, open your terminal/command prompt and run: dotnet tool install -g Microsoft.CST.AttackSurfaceAnalyzer.CLI Some time you get error like below: Step 2 – Verify Installation After installing, check that ASA works by typing: asa.exe --help This will list all available commands. ------------------------------------------------------------------------------------------------------------- Fixing Installation Issues When I first tried, I hit an error because NuGet wasn’t set up properly . If the dotnet tool install command doesn’t work for you, here’s the fix: dotnet nuget add source https://api.nuget.org/v3/index.json --name nuget.org Then re-run: dotnet tool install -g Microsoft.CST.AttackSurfaceAnalyzer.CLI Still stuck? You can always download the binaries directly from the ASA GitHub releases page . 👉 Once installed, the tool gets placed under this folder: C:\Users\\.dotnet\tools So if asa isn’t recognized, just navigate there and run the commands directly. ------------------------------------------------------------------------------------------------------------- Using ASA – CLI Mode The core idea is simple: take a snapshot, install or change something, then take another snapshot and compare. 1. Collect a Snapshot To capture the current system state (baseline): asa collect -a This collects info about files, services, users, ports, etc. 2. Compare Snapshots After making changes (e.g., installing an app), run another collection. Then export and compare: asa export-collect 3. Explore Options If you’re curious about all the available commands: asa.exe --help ------------------------------------------------------------------------------------------------------------- Using ASA with GUI If you don’t love CLI, ASA also provides a web-based interface . To launch it: asa gui Then open your browser and go to: http://localhost:5000 You’ll see a dashboard where you can visualize results, compare data, and interact with snapshots more easily. ------------------------------------------------------------------------------------------------------------- Features Worth Highlighting Tracks file system changes Monitors services, ports, and firewall rules Keeps an eye on user accounts and permissions Works across Windows, Linux, and Docker Offers both CLI and GUI  options Supports rule authoring  for custom checks ------------------------------------------------------------------------------------------------------------- Wrapping Up Attack Surface Analyzer makes it way easier to see what’s going on under the hood of your OS. Whether you’re testing new software, checking for unwanted changes, or just geeking out about system internals, ASA gives you a clear before/after picture. I recommend starting with the CLI for automation, then switching to the GUI if you prefer visuals. And don’t forget — if installation gives you trouble, adding the NuGet source usually fixes it. --------------------------------------------Dean--------------------------------------------------------