Transforming Bug Triage into Training: Inside the Making of Immersive AppSec Range Exercises
“We all know the pain of bug reports clogging up a sprint—we thought, what if we could transform that drain on time and morale into a challenge developers are excited to tackle?” Rebecca: Oh, I love that—turning bug backlog dread into bite-sized victories is brilliant. I’m excited to hear more, but first, congratulations on launching Immersive AppSec Range Exercises! This is a BIG deal! No one else does anything like this for developers. Naomi: Thanks! What can I say? My love for cybersecurity goes back to university capture-the-flag events. Pushing yourself outside your comfort zone with hands-on challenges is by far the fastest way to learn. My main goal was to bring that same energy to application security—there are loads of CTFs for pentesters, but not really for developers who need to sharpen their defensive and remediation skills. I also wanted this to be inherently team-friendly. Our individual AppSec labs are built for individual learning, but group dynamics demand different pacing and collaboration tools. Rebecca: Makes total sense. Offensive skills get the headlines, but developers need a solid, team-centric defensive playground too. So how did you translate that vision into the actual structure of our AppSec Range Exercises? Naomi: I anchored everything in the maintenance phase of the software lifecycle: Receive bug → Triage → Fix → Test → Merge. That mirrors real dev workflows, so participants don’t just patch vulnerabilities—they live the ticket management, version control, and testing cadence they’ll face on the job. [Inside scoop: When we build any security exercise, our team maps it to a real-world experience. In Immersive AppSec Range Exercises, a common SDLC workflow—teams learn best when they see exactly how it will play out in their daily sprints. ] Rebecca: I love that you’re training both mindset and muscle memory—jumping through the same process you’d use in production. Once you had that flow, what were the first steps to bring the framework to life? Naomi: Well, I knew that this project was going to need quite a few applications to house the functionality for the exercises, so I audited what we’d need from scratch versus what open source could handle. For ticketing, most OSS Kanban tools were overkill, so I built a lightweight app called Sprinter. Then for version control, we leaned on GitLab—it was quick to stand up and gave a familiar UI for branching and merges. Once those pieces clicked—vulnerabilities surfacing in Sprinter, code pushes in GitLab, and test runs in the Verification view—we had a minimally viable range exercise in action. Rebecca: A smart “build-what-you-must, borrow-where-you-can” approach. Seeing that prototype come together must’ve been so cool. Naomi: Absolutely. It was one thing to design on paper, but watching the pipeline live—tickets flow in Sprinter, GitLab merge requests, automatic test feedback—was a genuine “wow” moment. Rebecca: Speaking of “wow,” let’s talk scenarios. How did you land on “Blossom,” your vulnerable HR app in the Orchid Corp universe? Naomi: Well, we needed something with enough complexity to showcase the framework. HR apps hit three sweet spots: business logic richness, varied user roles, and sensitive data. Tying it into Orchid Corp—our fictional corporation for Immersive Cyber Drills—gave it narrative depth, especially for returning users of our Immersive One platform. Rebecca: And when you designed the actual vulnerabilities inside Blossom, what guided your choices? Naomi: I started with the OWASP API Top 10—that’s our gold standard for spotting the biggest threats. Then I looked at what slips through most scanners and frameworks—nuanced business-logic flaws and edge-case logic bugs—and made those the core of the challenge. To keep things well-rounded, I also added a few classics—things like IDOR, SSRF, and command injection—so every player gets a taste of both modern pitfalls and time-tested exploits. [Inside scoop: Mixing modern, real-world API flaws with a few known “gotchas” keeps Immersive AppSec learners guessing and builds confidence when they spot the unexpected.] Rebecca: I know you’re busy working on the next exercises we’ll release, but before we wrap, how did you test Blossom among developers and engineers? No doubt you wanted to make sure it delivered the right experience! Naomi: Yes, absolutely! We ran a pilot with our own Immersive engineers and a third party, creating a realistic dev team. Watching them collaborate—triaging, patching, merging—validated every piece of the design. Their feedback on pacing and hint levels let us polish the final release. It was one of my favourite days—seeing months of work click into place. After that, we shipped it to customers knowing it was battle-tested. Rebecca: This has been fantastic—thank you for sharing your full planning and development journey, Naomi! From initial vision to a live, collaborative exercise … I’m awed. You certainly put incredible thought and care into developing this revolutionary approach to AppSec training. Final Thought Security is a team sport, and training like Immersive AppSec Range Exercises is the fast track to confident, resilient DevSecOps teams. If you’re a developer or engineer looking to level up your remediation skills, have your team lead reach out to your Account Manager for a demo. In the meantime, watch a sneak peek of what your experience would be like in this demo below:Decoding Coding: Picking a Language
These days, more and more jobs can benefit from being able to write simple scripts and programs, especially in cybersecurity. For example, pulling data from an API, scraping web pages, or processing large data files to extract information – the list of uses is virtually endless! Tempting as it is to dive right in, there are several things worth thinking about before you begin. This article will discuss one of the most important choices – selecting a language. What to consider when choosing a language A basic understanding of programming languages can make your life easier, increasing your adaptability and finesse in different environments. But with tons of languages like Python, Java, JavaScript, Go, Rust, and more, which one should you choose? Here are the crucial factors to consider: What's available Can you install whatever language you like to run your code, or are there limitations? If you have an enterprise-managed computer, you might not be able to install new software or languages, and you may need to use the default options. For Windows, this is PowerShell. Bash Script is the equivalent for Mac and Linux devices, and Python is often available too. Your personal experience and interest This one might sound obvious, but it does matter. We learn better and faster when we're invested in the subject. Look at your previous experiences. Have you worked with any programming languages before? Did you enjoy them? For example, if you had a good experience working with Python, let that guide your decision! That said, don't shy away from learning something new if there's a good reason or you’re curious to do so. What's trending in your organization Does your organization or team predominantly use a specific language? Not only would learning that one help you communicate better with your colleagues, but it could also give you an edge while working with systems developed in that language. Plus, there’ll be plenty of people to talk to if you get stuck! The language's capabilities and nature Like people, different languages have different strengths. Some are fantastic for web development (like JavaScript), while others are better suited for system-level programming (like C). Python is often an excellent choice. It's considered easy to learn, incredibly flexible, and powerful due to the huge catalog of packages available. While it isn't as fast as many other languages, for most purposes, it's usually more than fast enough. Java is a very widely used object-oriented programming language and can be extremely fast. The learning curve is steeper than Python, but there are loads of learning resources available. JavaScript (not to be confused with Java!) isn’t as useful for quick standalone scripts or applications, but it's the dominant language for websites and browsers, so understanding it is practically a superpower for testing and manipulating websites and applications. C and C++ allow low-level access to memory and offer a lot of flexibility – incredibly helpful when evaluating systems with these languages at their core. Available tools and training Great tools can make tough jobs easier. Certain programming languages have robust toolsets that can help automate your tasks. For instance, Python has a wide array of libraries and frameworks that make handling big projects a cinch while saving you time and effort – why reinvent the wheel when you can just import it? Take a look at what training is available for the language you’re interested in. Older and more popular languages are likely to have more to choose from, but there’s loads out there and a lot of it is free! Also, consider what tools you might already have access to within your organization. Community and support If a programming language has a large active community, it means help is readily available when you get stuck. Languages like Python, JavaScript, and Java have strong communities and plenty of online resources available. Scope for growth If you're planning to learn a language, why not pick one that's in demand? Check job boards, look at industry trends, and see if learning a particular language can give your professional growth a boost! Summary Remember, no language is “the best". The best is the one that suits your needs and circumstances. You might even find mastering multiple programming languages useful over time. Just like speaking multiple languages, the more you know, the better you can communicate in different environments! Once you understand some of the basic programming concepts, like variables and loops, it’s easier to learn a second or third language. Learning a programming language may initially seem like climbing a steep mountain. But once you get the hang of it, you'll realize that the view from the top was well worth the hike! Want to take the next step? Here are some lab collections that may help you learn a bit more about PowerShell and Python: PowerShell Basics Offensive PowerShell Introduction to Python Scripting Share your thoughts If you’re new to coding, tell us what language you’re trying out! Why did you pick it, and would you make the same choice again? Are there any specific challenges you found or any relevant experiences you’d like to share?Secure Code Comments: One Easy Way to Steward Your Application Security Culture
While traditional code comments focus on explaining the code's functionality, security-focused comments are crucial to promoting secure coding practices throughout the development lifecycle (SDLC). By making this simple tactic part of your natural workflow, you can assert your knowledge and become a security champion. Let's explore how integrating security comments into your code can benefit you and the security team. Leading Forward Using Secure Code Comments Integrating security into your daily coding isn't just about ticking requirement boxes; it's about building a security mindset that makes you indispensable. Secure-code comments are low-hanging fruit for sharing knowledge, learning from others, and making security a seamless part of your day. Senior developers and application security champions can quickly and effectively educate other developers about best practices without leaving the comfort of their Integrated Development Environment (IDE). Best practice for code comments suggests emphasizing the why, not the what. Security-focused comments are no different. Meanwhile, they play a crucial role in promoting secure coding practices, enabling teams to: Explain Key Security Moves: Share the rationale behind specific security measures, such as input validation, encryption, and access control mechanisms. Flag Red Flags: Spot potential weaknesses in your code, like SQL injection, cross-site scripting (XSS), and unprotected data. Share Knowledge: Link to relevant security standards, guidelines, and resources and facilitate efficient code reviews. Enhancing Code with Security Comments–Two Examples Example 1: Preventing SQL Injection with Parameterized Queries (Python) Let’s consider a simplified Python function, which performs a simple insert operation into a database: def insert_user(conn, name, email): """ Inserts a new user into the 'user' table. Args: conn: A sqlite3 connection object. name: The name of the user. email: The email address of the user. Returns: None This function uses a parameterized query to prevent SQL injection vulnerabilities. See: CWE-89 https://cwe.mitre.org/data/definitions/89.html By using placeholders (e.g., `?`) and passing the actual values as separate arguments, we avoid direct string concatenation. This ensures that user-supplied input cannot be manipulated to modify SQL commands. """ sql = """INSERT INTO user (name, email) VALUES (?, ?)""" cur = conn.cursor() cur.execute(sql, (name, email)) conn.commit() cur.close() As you can see, in addition to the regular docstring, we succinctly mention why we’re using parameterized queries over string concatenation. We also reference a CWE and provide a link for anyone who wants to learn more. With just three extra sentences in a function comment, we’ve given less experienced developers who are code spelunking a quick lesson (or reminder) about why and how to prevent SQL injection. Example 2: Mitigating XSS Vulnerabilities with DOMPurify (React) Let’s take a look at another example, this time on a React frontend. Here, we’re knowingly doing something potentially dangerous but effectively communicating to other developers the mitigations applied. /** * Displays user-generated HTML content, sanitizing it with DOMPurify to prevent XSS vulnerabilities. * * This component uses `dangerouslySetInnerHTML` because the content being displayed *must* include HTML markup. * Alternatives like rendering plain text or using a limited subset of HTML tags are not sufficient for this use case. See: https://kanban.system/t/123 * **Security Considerations:** * * **CWE-79 (Improper Neutralization of Special Elements used in an HTML Page): https://cwe.mitre.org/data/definitions/79.html * This code directly addresses CWE-79 by sanitizing the user-provided HTML before rendering it. Without sanitization, malicious * users could inject JavaScript code that would be executed in the context of the website, leading to * XSS attacks. * * **Why not just use textContent?** If we used `textContent` or similar methods, any HTML tags in the user * input would be treated as plain text and displayed as-is. This would prevent XSS, but it would * also defeat the purpose of allowing users to input HTML in the first place. * * **Why DOMPurify?** DOMPurify is a widely used and well-maintained library specifically designed for * sanitizing HTML. It's more robust and secure than attempting to create a custom sanitization * solution. It handles a wide range of potential XSS attack vectors. * * @param {string} htmlContent The user-generated HTML content. This is assumed to be untrusted. * @returns {JSX.Element} The sanitized HTML rendered within a div. */ function SafeHTMLDisplay({ htmlContent }) { const sanitizedHTML = DOMPurify.sanitize(htmlContent); return ( <div dangerouslySetInnerHTML={{ __html: sanitizedHTML }} /> ); } This time we go into more detail about the why. Let’s break it down: First, it’s important to acknowledge that the original approach isn’t best practice. Second, you can level up developer awareness about alternative options.Then, connect the dots for maximum impact, sharing why this approach is required to satisfy product requirements. Finally, it’s important to detail security considerations with CWE IDs, codifying the weakness you’re proactively mitigating; yes, you can even justify the introduction of another dependency compared to a custom implementation. Any future developer tasked with modifying the comment feature will quickly understand the importance of keeping this mitigation rather than “cleaning up the code” because it still functions “the same” without it. As an AppSec developer or security champion, you’ve just avoided another security report being raised because of a regression introduced by an over-eager junior developer. It's well worth the 15 lines of extra code. Even better, any security engineer performing a secure code review will be much more confident that their developer understands why they wrote the code the way they did. This knowledge, in turn, expedites that coveted ‘approve’ on their pull request, reducing the time to get the code safely into production. Identifying and codifying vulnerabilities with Find the Flaw Setting the tone with security-focused comments largely falls to the lead developer or security champion, presenting an easy opportunity for aspiring champions to stand out. Remember, the goal is to identify and codify weaknesses in code before or as it is being written; this approach ensures others can craft easy-to-understand security comments too. Whether you’re just starting out or looking to grow your skillset, Immersive AppSec’s Find the Flaw collections provide ample opportunities to build critical DevSecOps muscle memory. You’ll learn to identify various common vulnerabilities in code and recognize what CWE IDs they correspond to. Writing security-focused comments will feel like second nature when you're coding up a storm! Beyond Code Comments: Empowering Your Manager to Recognize the Power of AppSec Training Code comments are a valuable AppSec tool, albeit only one piece of the puzzle. To cultivate a developer-led security culture, organizations need managers who recognize the power of comprehensive training programs for their elite developers. These programs support proactive developers with the knowledge and skills to build secure applications from the ground up. As a result, the organization achieves development velocity SLAs and application security simultaneously. Remember to share your experience learning by doing, gaining the attackers’ perspective, which Immersive Labs AppSec offers. Your manager and teammates should recognize the value of using safe, real-world scenarios and interactive exercises, such that the training you do (now) targets the problems you have (now). Share your thoughts Check out this Find the Flaw collection and then share your thoughts with The Human Connection community: For developers: Does adding security rationale to your comments feel like an ‘easy enough' lift? For security champions: Are you already using this technique or something similar? How have you convinced other developers to adopt this style of commenting?Human Connection Challenge: Season 1 – Scanning Walkthrough Guide (Official Version)
Time’s Up! Congratulations to everyone who completed Lab 2: Scanning from the Human Connection Challenge: Season 1. In this walkthrough, I'll share some strategies for efficiently completing the lab, based on my perspective as the author. Remember, there are often multiple ways to approach a challenge, so if you used a different method and succeeded, that's perfectly fine! The goal is to learn, and I hope these notes help clarify any steps and reinforce key concepts for the next challenge. This challenge has now ended, but the lab remains available for practice. While prizes are no longer up for grabs, you can still complete the lab and use this walkthrough guide for support if needed. I’ve also used placeholders in some of the commands that would give away an answer directly, so if you see anything enclosed in angle brackets, such as <name server>, please make sure you replace it with the actual value, such as nameserver. With all that considered, let's get started. Overview Task: Identify the name server records of tinytown.bitnet. 1. What is the IP of the first name server for tinytown.bitnet? You’ll first need to open a Terminal on the Kali desktop. Next, you’ll need to query the DNS Server IP (found in the Machines panel) about the tinytown.bitnet domain using the nslookup (Name Server Lookup) tool. You’re specifically looking for NS (Name Server) records, so you can use the -type=ns parameter with nslookup to specify this: nslookup -type=ns tinytown.bitnet [DNS Server IP] The output of this command will return two name servers for the domain labelled with 1 and 2. Your next step is to identify what IP address is associated with the first name server (1). To do this, you can use nslookup along with the name server, domain, and DNS Server IP: nslookup <name server>1.tinytown.bitnet [DNS Server IP] This command will then return an IP address for the name server. 2. What is the IP of the second name server for tinytown.bitnet? As you’ve already identified both name servers, you’ll just need to run the previous command, except with the second (2) name server: nslookup <name server>2.tinytown.bitnet [DNS Server IP] You’ll then find the IP address associated with it. Task: Identify port service information for Target 1. 3. What service version is running on port 53? A network scanning tool like Nmap can help you identify the service version running on a specific port. To do this with Nmap, you can use the -sV option for service detection: nmap -sV [Target 1 IP Address] The output will show what service version is running on port 53. 4. What is the full service banner of port 22? There are a couple of ways to find the full service banner of port 22 – such as with Nmap or Netcat. If you’re using Nmap, you can modify the previous command to include the “banner” script along with the port number: nmap -sV -script=banner [Target 1 IP Address] -p22 The command line will then display the service banner from port 22. You can alternatively use netcat to manually connect to the SSH server. When a client connects, Netcat may present a banner that contains version information. To use Netcat, you’ll need the nc command along with the Target 1 IP address and specify you want to connect to port 22: nc [Target 1 IP Address] 22 When you run this command, the banner appears before the terminal hangs. Task: Identify a token on one of the ports. 5. What is the token? With the previous Nmap command, you initially found that three ports were open on Target 1. However, you’ll need to do a more thorough network scan to find another open port, one not initially found with the previous scans. To do this, you can expand your port scan to cover a much wider range by using Netcat to scan for open ports from 1 through 9000: nc -zvn <Target 1 IP Address> 1-9000 Here, -z will scan for listening services but won’t send any data, -v is verbose mode, which provides more detailed information, and -n tells Netcat not to resolve hostnames via DNS. This command will reveal a fourth open port. Now, you can use Netcat to connect to this port: nc <Target 1 IP Address> <open port> The token will then be displayed in the terminal. Task: Scan the TLS configuration on Target 2. 6. How many protocols are enabled? To scan for SSL/TLS configurations, you can use the sslscan tool. By default, sslscan scans port 443 and will return supported server ciphers, certificate details, and more. You can use sslscan like this: sslscan <Target 2 IP Address> The returned output will be verbose, but you can find and count the number of enabled protocols under the SSL/TLS Protocols subheading. 7. Name an enabled protocol. Using the previous output, name one of the enabled protocols. 8. What exploit are the protocols NOT vulnerable to? Using the same output, scroll down through the results until you find a subheading that’s named after a vulnerability and contains a similar string to: <Protocol> not vulnerable to <vulnerability name> The vulnerability has the same name as the subheading. Task: Identify and extract information from an SMB share on Target 3. 9. What Disk shared directory can you access? To extract information from an SMB (Server Message Block) share, you can use the smbclient tool. First, you’ll need to list the SMB shares on the target using the -L flag (the list/lookup option) with: smbclient -L //<Target 3 IP> You’ll then be prompted for a password, but you can press Enter to skip this. A list of SMB shares will then be displayed, three of which are shown to be a Disk type, so you know the answer will be one of these. You can now begin to go through the list and try to connect to the shares with: smbclient //<Target 3 IP>/<Sharename> However, this time when you’re prompted for a password and you press Enter, you might encounter a message when you try and connect to a share: NT_STATUS_ACCESS_DENIED If you attempt to connect to all shares, you’ll find you can connect to one share without a password. You’ll then be greeted with the following prompt to show the successful connection: smb: \> 10. What is the token stored in the directory? Now that you’re connected, you can execute commands to interact with the SMB share. If you run ls, you’ll find a token.txt file in the current directory. You can then download the file from the share onto your local machine with: get token.txt On the Kali desktop, open the Home folder and the token.txt will be inside. Open this file and find the token. 11. What is the username stored in the directory? After you’ve run ls in the SMB share, you’ll find not only token.txt, but also a file named creds.txt. Use the same command as you just did previously to download the file onto your machine: get creds.txt This file will also be downloaded to the Home folder, where you can find a username and password. Task: Identify open services on Target 3. Task: Connect to Target 3 with the previously found credentials. 12. What is the token stored in the user's /Documents directory? For this final task, you first need to scan the target using Nmap. You’ll find that if you attempt to scan the target without using the -Pn flag, you’ll get a response saying that the host seems down. However, if you run Nmap with -Pn, you’ll find some ports are open: nmap -Pn <Target 3 IP Address> However, the ports returned from this command don’t offer a way to connect to the target. You’ll also need to scan the 6000 most popular ports: nmap -Pn --top-ports 6000 <Target 3 IP Address> These results will now show two additional ports are open regarding the Web Services Management (Wsman) protocol, which is used to communicate with remote machines and execute commands. One of the tools that implement this protocol is Windows Remote Management (WinRM) which is Microsoft’s implementation of Wsman. Knowing this, you can now use Metasploit to interact with the target. In your terminal, run: msfconsole Once loaded, you can use the the following auxiliary module to connect to a system with WinRm enabled and execute a command with: set cmd ls You’ll then need to set the following options, using the credentials you found in the creds.txt file: set username <username> set password <password> set rhosts <Target 3 IP Address> Next, you need to set the cmd option with the command you want to run. If you use the ls command, you’ll be able to find what out files are in the directory you connect to: set cmd ls With all the options set, you can now run the module: run The results of the executed command will be printed on the screen and also saved to a directory, but both show the existence of a token.txt file in the current directory. You can now set the cmd option to type token.txt in Metasploit: set cmd type token.txt Once set, use the run command to send the updated command: run The contents of token.txt will then be displayed on the screen and outputted to a file. Tools For this challenge, you’ll use a range of tools including: Nslookup Nmap Netcat Sslscan Smbclient Metasploit Tips You can use different tools and parameters within those tools to scan for and find information, so don’t be afraid to try out a few different things! If you want to learn more about some of the tools within this lab, take a look at the following collections: Reconnaissance Nmap Infrastructure Hacking Introduction to Metasploit Post Exploitation with Metasploit Conclusion The steps I’ve laid out here aren’t the only way to find the answers to the questions, as long as you find the answer, you did it – well done! If you found another way to find some of these answers and think there’s a better way to do it, please post them in the comments below! I hope you enjoyed the challenge and I’ll see you for the next one.Making the Most of the Custom Lab Builder: Tone of Voice
Now you can build your own labs in the Custom Lab Builder, we thought we’d provide some guidance on writing with a strong tone of voice to ensure your labs are as engaging as possible. This blog is the third in a series on making the most of the Lab Builder, looking at what we call the Four Cs. Ensuring your writing is… Conversational Concise Conscious Consistent The previous two posts looked at accessibility and inclusivity. This post focuses on tone of voice and how to write authentically to ensure your audience engages with the lab and remembers the message you’re trying to teach them. Writing well For most of your life, you’ve probably been told to write properly. Avoid contractions at all costs. Use complex sentences with plenty of fancy connecting words like “furthermore” and “moreover”. And never start a sentence with “and”. This formal style works really well for some industries. Academia is traditionally an incredibly formal area when it comes to the written word, as is the broadsheet newspaper realm. This is often to reflect the work’s sincerity, to avoid weakening a writer’s reputation, and to present ideas consistently and objectively. But Immersive Labs believes writing can be sincere and objective without being so... dull! Be conversational Copywriting is increasingly conversational, appearing everywhere from LinkedIn posts to the back of your milk carton. This style engages readers by feeling personal and authentic, aligning with Richard Mayer’s Personalization Principle, that people learn more deeply when words are conversational rather than formal. A human-to-human copywriting style makes sense for Immersive Labs, as we’re all about focusing on the humans behind the screens. When using the Lab Builder, we recommend writing your labs in an engaging, approachable style to create a modern, user-friendly learning environment. But conversational doesn’t mean sloppy. It’s about presenting ideas clearly and confidently, helping users feel at ease while they learn. Use everyday, concrete language Using fancy, complex words doesn’t make content better – it can actually distract readers and undermine clarity. Instead, prioritize clear, straightforward language to ensure your message is easy to understand, especially by users with cognitive disabilities. Avoid overly poetic phrases, figures of speech, idioms, or ambiguous language, which can confuse or overwhelm readers, including those with autism spectrum conditions. Strive for clarity to help users grasp your message the first time, keeping their needs front and centre. Address the reader Authenticity is all about gaining your reader’s trust. We recommend speaking directly to them in your custom labs by using “you” throughout your copy. This handy trick also avoids any ambiguity when it comes to practical tasks. Take the following example. “In this lab, the machine must be analyzed and IoCs must be extracted.” Instead of being vague and passive, we recommend talking directly to the reader and telling them exactly what they need to do. “In this lab, you need to analyze the machine and extract IoCs.” Or better yet, you can be even more direct by cutting that down even further: “In this lab, analyze the machine and extract IoCs.” Our labs and scenarios frequently talk directly to the reader. Users are more likely to stay engaged when they’re spoken to, not at. Use contractions Contractions instantly make your writing more conversational by mimicking natural speech. Combining words like "it is" to "it’s" or "you are" to "you’re" adds a touch of informality that feels approachable and inclusive. While once discouraged in formal writing, contractions are ideal for a modern learning environment, making text easier to read, understand, and remember. Be concise Writing in plain language is good for all users, but can make a massive difference for neurodivergent users, those who struggle to focus, those who hyperfocus, or maybe those who find reading difficult. We follow recommendations from the Advonet Group, the British Dyslexia Association, and Clark and Mayer’s Coherence Principle to ensure accessibility for a diverse audience – and you should too! Writing simply and clearly doesn’t mean trivializing content or sacrificing accuracy; it just makes your message easier to understand. After all, no one's ever complained that something's too easy to read! The difficulty comes when balancing this with technical content. How can you make advanced, complex cybersecurity topics clear and concise? Keep it short and sweet Sentences longer than 20 words become difficult to understand and can detract from the point being made. It’s easy for people’s minds to wander, so get to your point in as few words as possible. The same goes for paragraphs. Try and avoid long, dense walls of text. Nobody wants to read that, and it’s no good when thinking about accessibility. Keep your paragraphs to four or five lines, maximum. Get to the point Avoid adding unnecessary side notes to your labs, as they can distract from the main message and make learning harder. Unnecessary content distracts the learner’s attention from the main message, making them less likely to remember the core topic. It disrupts the connections between key messages and diverts the learner’s focus, making it harder to piece together the bigger picture. This is all down to cognitive load theory, which says that in general, humans can handle around four pieces of new information at any one time. To help users focus, stick to the lab's core topic and avoid overloading them with unrelated details. TL;DR When writing your labs with the Custom Lab Builder, ensure all your text is conversational to engage your users with the topic. And also make all your copy as concise as possible. Getting your message across in as few words as possible will reduce cognitive overload, boredom, and frustration. By focusing on being conversational, as well as being consistent and conscious (as we covered in the previous blog posts in this series), your readers will engage with your content better, remember the topic, and be able to put it into practice more easily – improving their cybersecurity knowledge and driving their cyber resilience. Share your thoughts! What do you think about these tone of voice tips when writing your custom labs? Have you tried to write your labs in a conversational yet concise way, and how did this go down with your users? Do you have any other suggestions for the community on how to write conversationally? We’d love to hear from you!Making the Most of Custom Lab Builder: A Guide to Writing Inclusively for All
Language shapes how people perceive and engage with content, so it’s crucial to consider the kind of words you use. Using outdated terminology can offend and disengage learners, as well as hurt a company’s reputation. This blog is the second in a series on making the most of the Lab Builder, looking at what we call the Four Cs. Ensuring your writing is… Conscious Consistent Conversational Concise The previous post in this series looked at accessibility. In this post, we’ll explore what it means to write consciously and inclusively, share practical tips, and show how our platform supports this critical effort. Why is inclusive language important? Inclusive language avoids bias, respects diversity, and ensures accessibility for all. In cybersecurity, it means using terms that foster collaboration and trust, avoiding outdated or harmful phrases, and creating welcoming and empowering content The Quality Team at Immersive Labs is committed to staying up to date with how language changes in the cyber industry. We regularly undertake research and speak to other industry professionals to ensure that our language is appropriate. Words to avoid We recommend avoiding specific terms that some people may find offensive, and some socially charged language that may have negative connotations. Non-inclusive language to avoid Preferred inclusive versions Whitelist/Blacklist Allowlist/Denylist White hat/Black hat hackers Ethical/Unethical hackers Master/Slave Leader/Follower, Primary/Replica, Primary/Standby Grandfathered Legacy status Gendered pronouns (e.g. assuming “he/him/his”) They, them, their Gendered pronouns (e.g. “guys”) Folks, people, you all, y’all Man hours, man power Hours, engineer hours, workforce, staffing Man-in-the-middle attack Machine-in-the-middle attack Sanity check Quick check, confidence check, coherence check Dummy value Placeholder value, sample value Crazy, insane Amazing, incredible, or any other appropriate adjective Socially charged words Preferred inclusive versions Native Built-in, default, pre-installed, integrated, core Abort Stop, cancel, end, force quit Cripple Disable, impair, damage, destroy, ruin Kill Stop, force quit, close, shut down Trigger Activate, initiate, cause, launch Unsure if a phrase you’ve used could be seen as offensive? Ask yourself: is this the most accurate and appropriate choice? Often, you can find a more descriptive word and avoid using these examples. Top tips for inclusive language Use writing tools Tools like Grammarly can help identify problematic words or phrases. You can create customized lists in Grammarly, which will then flag when a word has been used in your writing. Additionally, there are many inclusive language guides available online. Keep it short and sweet Use short sentences and paragraphs. Shorter sentences are easier to read, scan, and understand – especially for those with cognitive disabilities. Aim for sentences around 10–15 words, with variation for a natural flow. Avoid sentences longer than 20 words, as they can be harder to follow. Read aloud Proofread your work aloud to catch awkward phrasing, overly complex sentences, or insensitive terms. Hearing the words can help identify spots where clarity or tone might need improvement. Get a second opinion Ask a colleague to review your final version. A fresh set of eyes can spot language that might be unclear, inappropriate, or overly complicated. Share your thoughts Now that Lab Builder is here and you’ve had a chance to create your own content, how have you made your content more inclusive? We’re always looking to stay up to date, so if you have any further suggestions to add to our list of words to avoid or any other tips, let us know! We’d love to learn from you and grow the collective community knowledge.Making the Most of the Custom Lab Builder: Writing With Accessibility in Mind
What if someone tried to access your content who was visually impaired? Or who had cognitive difficulties? Or who was hard of hearing? Would they be able to understand the information you’ve provided and improve their cyber resilience? Our in-house copyediting team has created a series of articles to help you craft high-quality labs, aligned to the rigorous processes we follow. We embrace what we call the Four Cs to ensure all labs are: Consistent Conscious Conversational Concise These articles delve into each of these principles, showing how to implement them in your labs to create content that resonates with readers, enhances learning, and boosts cyber resilience. This post highlights how being conscious of your formatting can enhance accessibility for assistive technology users and how consistent formatting improves navigation for everyone. Rich text formatting Rich text formatting tools like subheadings, bullet points, lists, and tables in the Custom Lab Builder help organise information for easier scanning, better retention, and improved comprehension. Using these will ensure your content is consistent, accessible, and reader-friendly for everyone! Rich text formatting elements carry specific meaning, which assistive technologies rely on to convey information to specific users. Headings Visually, headings represent hierarchy through different font styling and allow users to quickly scan content. Programmatically, they allow users who can’t see or perceive the visual styling to access the same structural ability to scan. Heading elements should reflect the structure of the content. So your title should go in ‘Heading 1’ formatting, your next subheading will go in ‘Heading 2’ formatting, and so on. To ensure your content reads correctly to screen reader users, don’t use HTML heading styling to represent emphasis, and don’t use bold to make text appear like a heading. Lists (bullets/numbering) Always use bullets or numbered lists using the provided formatting to convey a list. A screen reader will announce that the following information is a list. Links How a link is formed significantly impacts usability. Consider the following sentence: “To find out more about this topic, complete our Intro to Code Injection lab here.” Links are interactive elements, which means you can navigate to them using the tab key. A user who relies on screen magnification to consume content may choose to tab through content to see what's available. The example above would be communicated as just “here”, which provides no context. They’d need to manually scroll back to understand the link’s purpose. Always use descriptive link text that clearly indicates its destination. Avoid ambiguous phrases like “here”. If that’s not possible, ensure the surrounding text provides clear context. “To find out more about this topic, complete our Intro to Code Injection lab.” Bold Only use bold for emphasis! Avoid italics, capital letters, or underlining (reserved for hyperlinks) to prevent confusion. Consistency in formatting reduces cognitive load, making your text more accessible. Bold stands out, provides better contrast, and helps readers quickly identify key information. Avoid italics With 15–20% of the population having dyslexia, italics are worth avoiding because research shows it’s harder for this user group to read italic text. Italics can sometimes bunch up into the next non-italic word, which can be difficult to comprehend or distracting to read. Media If you’re adding media to your labs, such as videos and images, it’s especially important to consider those who use assistive technologies. These users need to have the same chance of understanding the content as everyone else. They shouldn’t miss out on crucial learning. What is alternative text? Alt text describes the appearance and function of an image. It’s the written copy that appears if the image fails to load, but also helps screen reading tools describe images to visually impaired people. Imagine you’re reading aloud over the phone to someone who needs to understand the content. Think about the purpose of the image. Does it inform users about something specific, or is it just decoration? This should help you decide what (if any) information or function the images have, and what to write as your alternative text. Videos Any videos you add to your lab should have a transcript or subtitles for those who can’t hear it. Being consistent Consistency is a major thinking point for accessibility. We recommend adhering to a style guide so all of your labs look and feel consistent. We recommend thinking about the structure of your labs and keeping them consistent for easy navigation. In our labs, users expect an introduction, main content, and a concluding “In This Lab” section outlining the task. This helps users recognize certain elements of the product. It reduces distraction and allows easier navigation on the page. For example, some users prefer diving into practical tasks and referring back to the content if they need it. By using the same structure across your lab collections, your users will know exactly where to find the instructions as soon as they start. TL;DR It’s crucial to focus on accessibility when writing your custom labs. Utilise the built-in rich text formatting options in the Custom Lab Builder (and stay consistent with how you use them!) to ensure your labs are easy to navigate for every single user. By being conscious and consistent with your formatting, every user will engage with your content better, remember the topic, and be able to put it into practice more easily, improving their cybersecurity knowledge and driving their cyber resilience. No matter how they consume content. Keep your eyes peeled for the next blog post in this series, which will look at inclusive language. Share your thoughts! There’s so much information out there on creating accessible content. This blog post just focused on the language, structure, and current formatting options available in the Custom Lab Builder. Have you tried to make your labs or upskilling more accessible, and how did this go down with your users? Do you have any other suggestions for the community on how to write content with accessibility in mind? Share them in the comments below!From Feng Shui to Surveys: How User Feedback Shapes Immersive Labs
We’ve all been asked to give product feedback in one way or another – a pop-up message after completing a purchase, an email asking how your visit went, or a poll appearing on your social media feed. They all have one thing in common: a real person behind them, looking for valuable insights. I’m one of those people! My role as Senior UX Researcher involves speaking to Immersive users and gathering their feedback to help the company make tangible improvements. UX, or user experience, is at the heart of what I do. And it’s been around for longer than you might think. What is UX? It’s believed that the origins of UX began in 4000 BC with the ancient Chinese philosophy of Feng Shui, the spatial arrangement of objects in relation to the flow of energy. In essence, designing the most user-friendly spaces possible. A short skip to 500 BC, and you can see UX at play with the Ancient Greeks' use of ergonomic principles (also known as human factors), defined as “an applied science concerned with designing and arranging things people use so that the people and things interact most efficiently and safely.” In short, people have been concerned about creating great user experiences for thousands of years. How does Immersive get feedback? Bringing you back to the present day, let me walk you through a recent research study undertaken with Immersive Labs users and what their experiences and feedback led to. In May this year, we sent out a survey to our users asking them about their needs for customised content. The feedback was given directly to the team working on the feature, helping to inform their design choices and confirm or question any assumptions they had about user needs. In July, we invited users, including Training Manager and community member mworkman to take part in a pilot study for the Custom Lab Builder, giving them exclusive access to the first iteration of the feature. They could use the builder in their own time, creating real examples of custom labs using their own content and resources. This gave them a realistic experience and highlighted issues along the way. What does Immersive do with that feedback? In August, those users joined a call with us to provide their feedback and suggestions. From these calls, we gained insights and statistics that were presented to the entire Product Team, voicing our customers’ needs. We then used this to shape the direction of the lab builder feature before its release. Customers told us that they wanted to create labs based on their own internal policies and procedures, which would require more flexible question-and-answer formats for tasks. They also wanted more formatting options and the ability to add media to labs. In response to this feedback, we increased the number of task format types from three to five, and we’ll continue to add to this. We also added the ability to include multiple task formats in the same lab. Users also now have the option to upload images and include rich text within their custom labs, enhancing the layout and customisation experience. The Custom Lab Builder was released in October 2024 with an update pushed in December, and we’re still working on improving it! Throughout this first quarter of 2025, we’ve released more new features, including drag and drop, free text questions, and instructional tasks in the Lab Builder. How can you get involved? Once again, we’ll be calling on our users to give feedback on their experiences with these features, continuing to involve you in our design process to ensure that our products and experiences reflect what users are looking for. Throughout 2025, Immersive Labs will be providing opportunities for our users to come along to feedback sessions, have their opinions heard through surveys, and many more exciting chances to talk to the people behind the product. Follow our Community Forum for hot-off-the-press opportunities! For more guidance on Lab Builder, visit our Help Center.From Concept to Content: A Deep Dive into Building and Critically Analyzing Labs
Putting it all together The main bulk of the development work is building the labs. This usually comprises two parts that require different skill sets; one is putting together the written portion of the lab (such as the briefing, tasks, and outcomes), and the other is implementing any technical needs for the practical side of the lab. While some labs may focus more on one component than the other, this general overview of lab development will demonstrate each step of the process. Developing written content Regardless of the lab, the written content forms the backbone of the educational material. Even with prior knowledge and planning, additional research is essential to ensure clear explanations. Once research is complete, an outline is drafted to focus on the flow, ensuring the information is presented logically and coherently. This step helps enhance the final product. The final step is turning the outline into the final written content. Everyone approaches this differently, but personally, I like to note all the points I want to cover in a bullet list before expanding on each one. This method ensures all necessary information is covered, remains concise and clear, and aligns with learning outcomes and objectives. Technical implementation For practical labs, technical setup is key. Practical tasks should reinforce the theoretical concepts covered in the written portion, helping users understand the practical application of what they’ve learned. Before implementing anything, the author decides what to include in the practical section. For a CTI lab on a vulnerability, the vulnerable software must be included, which involves finding and configuring it. For general topics, a custom script or program may be needed, especially for niche subjects. The key is ensuring the technical exercise is highly relevant to the subject matter. Balancing the difficulty of practical exercises is crucial. Too easy, and users won’t engage. Too hard, and they’ll get frustrated. Tasks should challenge users to think critically and apply their knowledge without discouraging them. This requires iterative testing and feedback to fine-tune the complexity. The goal is to bridge the gap between theoretical knowledge and real-world application, making learning effective and enjoyable. Quality assurance and finishing touches The development process is complete, but there’s still work to do before releasing the content. We take pride in polishing our content, so the final steps are crucial. Checking against expectations Before the official QA process, we review the original plan to spot any discrepancies, such as unmet learning objectives or missing topics. While deviations don’t always require changes, they must be justified. Assuring quality A thorough QA process is vital for catching grammatical errors, technical bugs, and general improvements before release. Each lab undergoes three rounds of QA, each performed by a different person – two rounds of technical QA, and one for presentation. Some of the steps taken during technical QA include: Verifying written content accuracy, flow, and completeness. Ensuring all learning objectives are covered. Identifying any critical bugs or vulnerabilities that would allow users to bypass the intended solution. Providing small tweaks or changes to tasks for clarity. Assigning relevant mappings (NICE K-numbers, MITRE tags, CWEs). After technical QA, the lab is reviewed by our quality team to ensure it meets our presentation standards. Once all labs in a collection pass rigorous QA, they are released for users. The final step occurs post-release on the platform. Gathering and implementing user feedback Users are at the heart of everything we do, and we strive to ensure our content provides real value. While our cyber experts share valuable knowledge, user feedback prevents echo chambers and highlights areas for improvement. After new releases, we conduct an evaluation stage to analyze what went well and where we can improve. User feedback We gather quantitative and qualitative feedback to help us identify root issues and solutions. Quantitative feedback involves analyzing metrics like completion rates and time taken. We also examine specific changes, such as frequently missed questions or labs where users drop out. These are important things to note, but we avoid drawing conclusions solely from this data. This is where qualitative feedback comes in. Qualitative feedback includes user opinions and experiences gathered from feedback text boxes, customer support queries, and direct conversations. These responses are stored and read by the team and provide context beyond raw numbers. Channels such as customer support queries and follow-ups with customers also help us improve our content. Post-release reviews We conduct post-release reviews at set intervals after content release to analyze quantitative and qualitative data. This review helps us assess the entire process and identify areas for improvement. These reviews allow us to update content with new features, like adding auto-completable tasks for CyberPro. The reviews ensure our content remains current and enhances user experience. Wrapping up Hopefully, this blog post has provided insight into all the care we put into building and tailoring our content for users. This process has come a long way since we started making labs in 2017! Don't forget — with our new Lab Builder feature, you can now have a go at creating your own custom labs. If there's a topic that interests you and you want to share that knowledge with your team, making your own lab is a great way to do it! If there’s any part of the process you’d like to know more about, ask in the comments. Are there any collections that made you think, “Wow, I wonder how this was made”? Let us know!From Concept to Content: Laying the Foundations of a Lab Collection
Technical planning At this stage, we address niche technical details not covered in initial planning but crucial for polished content. Below is an example of the question-and-answer process used for the “Web Scraping with Python” collection. Should the practical sections of the content be created using Docker, for optimal speed and modularity, or does the subject matter require the use of a full EC2 instance? As there are no unusual requirements for the technical portion of the collection (such as needing kernel-level access, network modifications, or third-party software that doesn’t run in containers), the labs can run on Docker. This is a benefit not only for the overall user experience, but also allows for image inheritance during development, which will be demonstrated a bit later on. Are there any tools, custom scripts, or system modifications that should be present across the whole piece of content? The collection is based around writing Python scripts, so ensuring that Python is installed on the containers as well as any required web scraping libraries is a must. In addition, some considerations for user experience can be made, such as installing an IDE like Visual Studio Code on the containers. How can task verification be implemented to make sure it’s both robust and non-intrusive? In the case of this collection, implementing auto-completable tasks may be difficult due to the variety of ways users can create solutions, as well as the lack of obvious traces left by web scraping. Instead, it may be more appropriate to insert task solutions into a mock website that needs to be scraped, which the user can retrieve by completing the task and providing the solution in an answer box. Understanding the technical requirements for a piece of content helps to bridge the gap between planning and development, making it a crucial step. With some of the key questions answered, it’s time to move on to implementation. Creating base images It’s finally time to put fingertips to keyboards and start programming! The first part of implementation creates what all labs in a collection will be built on – a base image. This is a skeleton that provides all the necessary tools and configuration needed for the whole collection, using a concept called image inheritance. If you're new to containerization software like Docker, don't worry – image inheritance is straightforward. Docker containers use images as blueprints to create consistent, mini-computers (containers). This is useful for labs because it allows you to quickly create a pre-configured container without the overhead of setting up a virtual machine, saving time and system resources. This is where image inheritance comes in. Docker images can inherit traits from parent images, similar to how you inherit eye color from your parents. Instead of one central image for all purposes, you create a parent image with shared requirements and then customize descendant images for specific needs. Let’s use the “Python for web scraping” collection as an example again. Think about what kind of things would need to be present in each lab: An installation of Python so the user can run scripts. A code editor to write the scripts in. A mock website for the user to test their scripts on. The first two of these requirements are essentially the same in every lab; there’s no real need to change the installation of Python or the code editor, and in fact, it would be better to have them all be identical, which would result in a smoother user experience. The third, however, does need to be changed — the specific task requirements are going to be different from lab to lab, and the website files will need to change to accommodate this. Taking into account the requirements, an inheritance structure like this can be used: Base image – Python installation and code editor present Lab 1 – Custom website files Lab 2 – Custom website files Lab 3 – Custom website files … Structuring images this way saves time, disk space, and development work by reusing shared configurations. Next time… In part three of this mini-series, you'll learn about the final stages of content development: creating labs, quality assurance, and release. To be notified when part three is released, follow The Human Connection Blog using the bell icon. Meanwhile, feel free to ask questions about the content creation process or specific collections in the replies. Have you used the Lab Builder feature to make any custom labs yet?
