The born-left product security blog

Featured

AWS FTR (Foundational Technical Review) Checklist [XLS Download]

Only 43% of companies evaluate new products' data security and privacy before launch. And security is just one chapter of the story: how do companies optimize for security, reliability, performance, and costs all at the same time? FTR can help AWS Partners (those part of the AWS Partner Network) to review processes and tools to improve their solutions' quality. Plus, they get a shiny “AWS - Qualified Software” badge at the end. While AWS Foundational Technical Review is free price-wise, it doesn’t come for free. You must follow a long list of criteria to earn the certification, which involves thoroughly auditing your systems. This article explores how to approach FTR and some steps to get FTR-ready. What is an AWS Foundational Technical Review (FTR)? The AWS Foundational Technical Review (FTR) is a structured self-assessment process that evaluates the architecture of your software solutions. There are several versions of the FTR, one for solutions hosted in AWS and one for those hosted outside. The FTR process will take you through self-evaluation, a review process, and a remediation timeframe of up to six months at its conclusion. However, it doesn’t end there - you must file for a renewed review every two years and adhere to any updated requirements. The FTR has some overlap with the popular AWS Well-Architected Framework, which consists of six key pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. While the AWS Well-Architected Framework is recommended for every business, FTR is a smaller version, targeting AWS Partners. These guiding principles help ensure the quality and security of your software applications and reduce cloud costs. Getting Started with Your Foundational Technical Review The process for getting FTR approved is straightforward: Join the AWS Partner Network (APN): If you still need to register your company with the APN, join at no cost by creating your AWS Partner Central Account.Enroll in the software path: The FTR is part of the software path.Perform a self-review: Time to get busy. Establish a systematic review process and evaluate your architecture against the FTR Guide. If you find any shortcomings, take the necessary steps to remediate any issues before proceeding.Request an FTR review: Upon receiving your request, a Partner Solution Architect (PSA) will contact you and provide you with a checklist to complete upon receiving your request. He will review the submitted documentation and give you the all-clear or a list of required improvements. You can (and should) take advantage of AWS’s well-architectured tools, which will ask you questions and offer insights into potential issues you may encounter. Naturally, the tools will give you an overview of the Well-Architected Framework, but it can also provide insights into what needs improvement or fixing. You may also create custom lenses for your specific needs. While the process may seem straightforward, things get more cumbersome once you reach step 3. Reviewing the official FTR checklist requires you to review each item individually to review compliance. You must check off every item to pass your assessment and provide notes describing how you pass the requirements, so detail is of the essence here. Optionally, AWS recommends you to enable the CIS benchmark in SecurityHub and upload a CSV with the results of the automated checks as evidence. Lastly, you have to upload your architecture diagram. As you can tell, this task is highly manual and can take weeks, months or up to a year, depending on how secure your system is and the resources you have available. Jit can make this process more seamless and help you pass your FTR assessment without headaches. The AWS FTR security plan on your Jit account automatically maps the gaps related to the security requirements, thanks to various tools which scan your AWS environment and code and provide you with remediation as code and detailed guidelines. After following the recommendations or applying the remediation as code, your environment will be scanned again to ensure all the gaps have been covered. Critical areas of the AWS FTR (Foundational Technical Review) Reliability A reliable system is a system that has safeguards and recovery plans in place in case of disruptions, as well as the ability to adjust computing resources based on demand. Monitoring Activity: Monitoring and logging help you track and identify reliability issues. AWS provides services like Amazon CloudWatch and AWS X-Ray for this purpose.Testing and Mitigation: Performing regular stress tests will help identify bottlenecks or weak points in your system that could impact reliability.Backup and Restore: Regular backups and fast restoration strategies are crucial for maintaining data integrity. You can use AWS services such as Amazon S3 and AWS Backup.Disaster Recovery Plan: You must have a detailed plan for critical failure. Outline the program, and ensure your staff is aware of the procedures. Security Cyber attacks are an ever-present threat to connected resources, particularly cloud-based applications. Identity and Access Management (IAM): Create and manage AWS users and groups and use permissions to allow and deny their access to AWS resources. Follow the principle of least privilege when assigning roles to increase security.Logging and Monitoring: AWS offers services such as AWS CloudTrail for API logging and activity monitoring, Amazon CloudWatch for monitoring resources and applications in real-time, and AWS Security Hub for managing security alerts and automating compliance checks. Having robust logging and monitoring helps identify problems and fix them faster. Shifting Security Left: Security testing should be performed early in the SD/LC to prevent vulnerabilities from making it into the late stages of development and save time and money on remediation. You can use many security tools here, in particular looking for hard-coded secrets which are tied to one of the FTR requirements, which Jit can orchestrate into your CI/CD.Data Protection: Especially important for personal information, data encryption in storage and transit is essential for FTR and any other compliance regulations you must adhere to.Security Assessments: Perform regular security assessments and testing. You can use cloud security tools like KICS and Kubescape if you're cloud-native or hybrid. Jit can integrate with these and many other tools, enabling you to automate and manage various security tests from a single location. Plus, you get enhanced findings with insights from other tools and real-time fix suggestions - as shown in the example below. FTR is a win-win situation A well-architectured solution is the way to go, and the FTR is an excellent way of ensuring your application meets those guidelines. Following this checklist of critical points you must address will prepare you to undergo the official FTR process and get your well-deserved badge (with the added perk of having a fully secure and stable system). However, this process is still highly detailed, manual, and time-consuming. Jit’s AWS FTR Security Plan lets you automate the process of meeting FTR security requirements. It offers better visibility into your architecture’s security gaps directly related to the AWS FTR application process, making it easier for you to remediate these and pass your FTR assessment. Get started for free. One ticket to AWS first class, please! That’s not actually the official designation, but an Amazon Foundational Technical Review (FTR) certification can fast-track you into many currently locked perks and allow your organization to boost stakeholder and customer trust, thanks to the Amazon Partner Network (APN).

Development Forget Mono Repo vs. Multi Repo - Building Centralized Git Workflows in Python About This content is brought to you by Jit - a platform that simplifies continuous security for developers, enabling dev teams to adopt a ‘minimal viable security’ mindset, and build secure cloud apps by design from day 0, progressing iteratively in a just-in-time manner. ‍ This blog article summarizes a talk given by David Melamed, Jit CTO, at Pycon DE & PyData 2022 in Berlin. In every software development project, before even writing the first line of code, you gotta pick an architecture for your repo. Picking an architecture is not easy. There are many tradeoffs that need to be considered and this choice will impact future development Should I place all code in one place? Should I use microservices and follow the single responsibility principle? Should I manage all the codebases in a single repository, allowing for easy refactoring and creating a common culture across teams? Should I allow for independent deployments and versioning and more autonomous work in each team? Letting the teams decide which language they want to use or which web frameworks they are more comfortable with? Developers ask themselves these questions over and over when they are about to start a new project - I asked myself these questions while working on jit.io. Choosing the right model seems like a never-ending debate. Naturally, each model has its pros and cons. ‍ ‍Introducing centralized CI What if you could have a central place to keep your CI/CD pipeline configuration while finding a way to trigger it from every repository? What would it look like? Basically, you would need the ability to listen to every PR, using some backhand service that would trigger the CI pipeline automatically, with the relevant context, in order to clone the branch and run your tests on it. Watch the video below to explore a concrete example: One way to achieve some sort of centralized CI involves one recent feature introduced by Github: reusable workflows. Think of this as a way to only reference external files in each repo instead of copying the same file over and over. However, right now this feature is limited to public repositories only so it is not relevant for us. Also, the approach I am suggesting is providing more granularity in terms of control, since there is a central place where you can decide with a logic you define how to trigger the centralized workflows. Implementing CI architecture in real life - what do you need? Here's what you need to do in order to implement the CI architecture in real life: #1: Create a Github application A Github application will give you access to the GitHub API and the ability to register and receive all the events about open PRs, so you will be able to trigger your CI workflow remotely. ‍#2: Create some simple backend to listen to PRs Async library: aiohttp + aiohttp-devtoolsGithub API wrapper #3: Use ngrok to get a public URL for local development The ability to have a public URL is important since GitHub needs to send us the open PR events. Using ngrok can create a tunnel that provides you with a unique URL. Building a centralized Linter - a detailed tutorial Watch this video to learn how to build a centralized Linter: And lets see this in action: Summary In summary, the short answer to the question of whether you can choose an architecture without worrying about multi-repo or mono repo is YES. I have fully demonstrated, in detail, how to create a centralized linter with a feedback loop that updates the PR status of the original repo. The main advantage of a centralized link linter is that it releases the developer from thinking about adding IDs each and every time. Centralized CI can help developers overcome the never-ending debate of choosing a specific app architecture. Armed with this knowledge, you’re ready to choose the right architecture for your app.. Good luck! 😉 ‍

a hand writing open source on a blackboard

Development 5 Essential open source product-security tools for developers you need to know About This content is brought to you by Jit - a platform that simplifies continuous security for developers, enabling dev teams to adopt a ‘minimal viable security’ mindset, and build secure cloud apps by design from day 0, progressing iteratively in a just-in-time manner. ‍ As cybersecurity becomes increasingly important in software development, the “shift left” security approach is widely recognized as a best practice for ensuring superior product security. Numerous traditional security firms are introducing shift-left products and capabilities, and the concept is gaining traction. However, the industry is beginning to understand that merely “shifting left” is insufficient in a world of continuous delivery. High-speed, forward-thinking development teams are adopting a new “born left” security strategy. In this approach, security considerations - like many other product aspects - are addressed right from the first line of code. Product security is not just delivered by the development team; it is owned by them. Recognizing this shift and the potential additional burden on already strained developers, the industry is seeking solutions and tools to help developers manage security while maintaining agility. We understand that today’s “shift left” open sources are not alleviating the overhead placed on developers due to the noise created and the burden of learning security and navigating each open-source tool. It’s our responsibility to address this issue. Nevertheless, some open source security tools are more developer-friendly than others. That’s why we’ve compiled a list of five security tools that we believe developers should be aware of. This article provides a brief overview of the top open source software and explains why we consider them to be developer-friendly. We will delve into each security area they cover in our forthcoming post and discuss why you should consider using them. What makes a tool developer-friendly? I first wish to define what I mean by ‘dev-friendly’ tools. To me, a dev-friendly tool makes developers' (and dev leaders') lives easier by either making tasks simpler or speeding up processes. To be more specific: Open source Open-source software is free, so there is no need for budget approval, and you can try out a tool without having to commit to it. Instead of lengthy selection processes, you can simply try it and see how you like it. In addition, and it is particularly critical for security tools, they let you read the entire source code so that you don't have any surprises regarding what actions the tool is performing when running it in your environment. Runs locally first... Running code locally from your terminal allows software developers to launch and test code with one simple command. The ability to run a tool locally ensures that you can get immediate feedback and easily tweak the configuration. When launched from a container, you don't even have to bother with possible environment issues related to compilation. ... and then in the CI/CD pipeline Tools that can be integrated in the CI/CD pipeline have a higher value. Once I have used a tool locally and found it to be useful, then, next, I would like it to run continuously as part of my development lifecycle - and not only on my local machine, using up my local resources. Of course, once a tool and process is part of the pipeline, the benefits are also extended across the entire dev team and codebase. So, start locally is an advantage, but being then able to easily merge into the environment is an advantage as well. Part of the developer work environment Developers should not be wasting time switching between development tools and security tools. All the tools on this list either run in the CI/CD pipeline (e.g. Github Actions) or as a plugin into the IDE. Great Documentation I believe this requires little explanation... Readily available documentation made for dev professionals can make or break smooth usage. With great “how-to” documentation, ramp-up time is much shorter. The better the documentation, the shorter the learning or troubleshoot curve and the easier the tool is to adopt. Configure the output format If you can output the results of a certain tool in multiple formats, you then allow yourself to pipe results into another tool through an API or other form of integration, allowing you to manipulate and analyze results in other tools. If results are only readable by humans, what you can then do with those results is limited and requires human effort - i.e. time that you simply don’t have. So without further ado, 5 security tools for developers you should know Based on the above 5 criteria, I’ve collected five security tools that are dev friendly. The list aims to cover various family of code analysis tools that should be part of some minimal requirements for security: Static application security testing (SAST)Dynamic application security testing (DAST)Hard-coded Secrets detectionInfrastructure as Code analysis (IaC) Pycharm Python Security Scanner is a security scanner for Python code wrapped as a Pycharm plugin, checking for vulnerabilities while also suggesting fixes. Alongside acting as a comprehensive security scanner, it also offers some additional extensions that can run dependency check analysis as well. What makes it unique is that beyond being a plugin, it also available as a CI/CD workflow for GitHub Actions in the Github Marketplace. ‍ Semgrep is a highly-configurable SAST tool, looking for patterns in the syntax tree. It can either run locally using Docker or be integrated into the CI/CD pipeline with Github Actions. Results are delivered as JSON files, allowing you to pipe the results into other tools, like jq in order to manipulate them. ‍ Gitleaks is a great project used for detect very efficiently high-coded secrets based on a configuration file containing hundred of built-in regex expressions tailored to find API keys of popular SaaS. It can run locally using Docker and or be integrated into the CI/CD pipeline with Github Actions. Results are delivered in various formats. The rules can be easily extended to match your internal patterns. ‍ OWASPs Zed Attack Proxy (ZAP) is another open-source tool, used for dynamic scanning (DAST). It can run locally using Docker and is providing a Github workflow to run in the CI/CD pipeline. The common output for this tool is a report in HTML but you can also get it in JSON using some addon. KICS is used to perform code static analysis of infrastructure and includes about 1,400 rules supporting various platforms like Terraform, CloudFormation, Ansible or Helm Charts. It can run locally using Docker and can be integrated into the CI/CD pipeline with Github Actions. Summary - Some thoughts on high velocity development and security At Jit, our mission is to provide developers with an end-to-end solution for owning product security, from planning, through open-source orchestration, following an MVS approach (Minimum Viable Security). Development teams are being tasked with end-to-end responsibility and ownership of their products, while all along there’s the pressure to ship code to production with high velocity. Like I mentioned above, while dev friendly security tools offer great benefits, the growing responsibility assigned to developers requires a shift in today’s approach - one that requires a minimum viable mindset and automated orchestration, so that devs will be able to own product security without compromising on velocity.

News Three Things to Look Forward to at OWASP Global AppSec DC 2024 It’s that time of year again, we’re super excited to be sponsoring and partnering with community friends at the upcoming OWASP Global AppSec in Washington DC. We’ll be at the booth with our partners Slim.AI, and are planning on making some noise. Three things to look forward to at OWASP Global AppSec DC . Jit is excited to be on the ground in a joint booth with the Slim.AI team to demonstrate some of our new capabilities - from teams to multi-plans and more, and to offer some pretty nifty swag.We’ll also be unveiling some new and exciting integrations like support for Semgrep Pro and support for both its excellent SAST and SCA capabilitiesWe’re also excited to be joining forces with some awesome co-sponsors to host a happy hour - join Jit, Semgrep, Impart Security, Oligo and Pangea When: October 29th 7:00pm - 9:00pm Where: Cuba Libre 801 9th St NW suite a, Washington, DC 20001 If you’re heading out to OWASP Global AppSec DC (October 30-31st in Washington DC), join Jit along with co-booth presenters Slim.AI and integration partners like Semgrep, for some fun on the ground. ‍ ‍ At our booth we will be demoing new and exciting capabilities, like the recently unveiled Team View capability, multi-plans for different use cases - from AWS FTR jit to OWASP Top 10 and OWASP ASVS, and even compliance programs like SOC2 coming soon. These will enable organizations to apply the technical security controls required to achieve compliance with common standards and industry frameworks. If you’re on the ground you can see these in action, check out some of our latest features and integrations. Jit has also invested quite a bit in supporting a wide range of OWASP tooling and frameworks - including OVS and now just in, ASVS in our multi-plans, alongside Dependency Check and ZAP. To provide end to end security of your entire application stack. One of our featured integrations is new support for Semgrep Pro which further augments the OSS Semgrep’s capabilities, and brings you both SAST and SCA support out of the box with a wider ruleset and remediation capabilities. Jit + Semgrep together = instant security for nearly all programming languages and stacks. In addition to Semgrep’s wide support for a diversity of programming languages, Jit’s own team has built AI-based detection and remediation capabilities for Semgrep to enhance the already stellar Semgrep scanning capabilities. Come say hi to both Jit and Semgrep and learn more about this partnership and native integration in Jit, and what’s coming next on the joint roadmap (which is going to be pretty great). No conference can be complete without some community fun. Join us at a joint happy hour with the Semgrep team to let loose a bit after conference hours and to meet and network with OWASP community friends. If you haven’t yet done so, make sure to RSVP and join us at ‍ ‍ Join us in Washington DC on October 29th and salsa your way into Havana Nights - the official OWASP Global DC kick off party. This event hat is sponsored by Semgrep, Jit, Impart Security, Oligo and Pangea this fiesta promises to be an unforgettable celebration of cybersecurity and Havana's vibrant culture. Dust off your Panama hats and don your best tropical attire and you might just walk away with the Best Outfit prize. For the cigar aficionados, our expert roller will be showcasing their skills, crafting hand-rolled artisan cigars to take home. This event is open to all OWASP Global attendees, so join us on October 29th at Cuba Libre for a night in Havana. We look forward to seeing you! When: October 29th 7:00pm - 9:00pm Where: Cuba Libre 801 9th St NW suite a, Washington, DC 20001 We’re not done yet! Jit loves to splurge on stellar swag - so stop by, say hi, watch a demo and get some kickass swag! We’re happy to meet any and all attendees and show you the truly great stuff coming soon. ‍ So with all this in mind, if you’re on the ground at OWASP Global AppSec DC, the Jit team would love for you to say hi. Book a demo to get early access to swag and features. ‍ ‍

Security What is Shift Left Security and 7 Steps to Get Started In today’s fast-paced, cloud-native world, software engineers are empowered to do much more than just write code. The linear structure of traditional security assurance processes owned fully by information security teams is no longer effective or efficient, creating bottlenecks and delays in software delivery. As such, DevOps teams are shifting left many IT functions like infrastructure provisioning and testing. However, 44% of development professionals still consider security teams primarily responsible for application security, while 49% of security professionals put this responsibility on their development team’s shoulders. This disconnect between developer and infosec workflows hinders developer productivity. Plus, it makes security no man’s land - which isn’t a great place to be considering the growing number of cyberattacks across development and production stages. So what is the solution? An approach that makes code and application security assurance a joint cross-departmental effort - also known as shift left security. What is shift left security? Shift left security (or shifting security left) is an approach to application security with an emphasis on detecting and addressing security issues as early as possible in the SDLC through Security as Code practices. Coined by Larry Smith in 2001, shifting left is a general term for integrating quality assurance in software development processes. When applied to cybersecurity, shifting left entails breaking down organizational and technological silos between security and development teams and enabling quick and smooth resolution of security issues earlier in the deployment timeline through effective collaboration. It’s worth noting that, contrary to common misconception, shift-left security is not about making developers experts in security and compliance tools and practices or placing them in charge of all things application security. Instead, this approach empowers software engineers by providing them with knowledge and tools (think SAST, DAST, and SCA security solutions) to prevent and mitigate security issues in their code. Similarly, it provides infosec teams with effective feedback loops for resolving issues discovered at any stage of the SDLC. When right is wrong: why you need to shift security left You can’t shift left something that doesn’t have a strong foundation on the right. Shifting security left is best implemented as part of an organization-wide cybersecurity strategy that enables integration and collaboration across teams, departments, and the C-suite. So, why are businesses shifting security left? Higher efficiency 2023 is set to be a record-breaking year for supply chain attacks. With the increasing frequency and severity of cybersecurity attacks, developers are pressured to mitigate risks faster and more efficiently. Shift-left security not only enables developers to spend less time chasing urgent security bugs but also saves businesses money, allowing more time for innovation. With more automation and fewer pre-deployment barriers, developers can produce secure code more efficiently and effectively without increasing technical debt. Reduced costs Waiting for the later stages of development to detect and repair security issues can result in costly fixes, even if the vulnerabilities that made it onto public-facing servers are not exploited in a breach. Some studies suggest that the cost of repairing defects at later stages of the SDLC can be as high as 640 times the cost of repairing them at the development stage. This is especially true if the system needs to be taken offline to wait for highly critical fixes (costing the business money) and when you need to make in-depth architectural changes to address the threats. Faster time-to-market Discovering security issues further down the delivery pipeline causes more delays in delivery than their discovery and remediation at the early stages of the SDLC. Problems detected in source code scanning are much easier and faster to fix than issues discovered after release. They are also less likely to cause significant setbacks in your planned delivery timeline. Improved customer trust With fewer vulnerabilities reaching production environments, you get fewer potential breaches. If your application is deemed risky, you are in danger of losing the trust of your customers. Ensuring your app is safe is especially critical in highly regulated industries like financial services and government contracts. 7 Steps to Get Started with Shift Left Security 1. Assess your SDLC and attack surface Before you can shift security left, you must have a complete understanding and in-depth view of how and where code moves from the developers’ minds to production. This process should involve documenting how software flows between people, devices, and third-party services. Once you’ve documented the flows, processes, and third-party vendors that may be involved in developing and delivering your applications, you can plan your attack surface management strategy to begin to find and fill the security gaps. At this point, it’s also essential to understand how code and application security assurance are managed today and where in your pipeline you test for vulnerabilities. 2. Ensure a collaborative security feedback loop Promoting a DevSecOps culture throughout the organization and including development, operations, and security professionals in the distribution of tasks and responsibilities in the security feedback loop is vital for the success of any shift-left security initiative. By promoting communication and empathy among the participants in securing your SDLC, you can design a process of collaboration that is fast, clear to all participants, and doesn’t create bottlenecks or friction. 3. Automate security testing The importance of automation in shifting security left cannot be overstated, and it can prove to be a “quick win” for your shift-self security strategy. You can integrate SAST and DAST, Interactive Application Security Testing (IAST), Runtime Application Self Protection (RASP), secret scanning, and dependency inspection into your CI/CD process while employing battle-tested OSS solutions like Semgrep. Jit can integrate with various open-source security tools to automate all security testing across your CI/CD. Moreover, with Jit’s DevSecOps orchestration platform, you can enable automatic remediation for common vulnerabilities and misconfigurations. In those cases, the suggested fix is displayed to the developer in the PR itself, and they can accept or reject it with a single click. Here’s an example of Jit’s remediation suggestion in GitHub: 4. Train your teams in secure coding standards While 85% of companies have a security awareness and training program, 56% of leaders still believe their employees lack security knowledge. Shift-left security entails a shift in responsibilities among product, development, security, and operations teams and, as such, requires continuous and practical training to ensure everyone can rise to their responsibilities. For developers, it’s essential to instill secure coding standards through cybersecurity awareness training and guidance. 5. Embed policies and guardrails into your pipelines At its core, shifting security left focuses on empowering and enabling software developers to secure their applications better. Offloading some tasks from security teams to automation through Policy as Code allows these teams to speed up deployment and remediation. Creating and automating security policies in your pipeline will enable you to set consistent boundaries and guardrails in which developers can operate freely and deploy more secure code with no added effort or changes to their workflows. Here’s a simple graphic showing how Policy as Code eases policy enforcement through automated rules and conditions: 6. Keep detailed documentation Storing detailed and updated documentation of code changes, security measures, and threat assessment is critical, especially as you add new security solutions to your toolchain. Thorough documentation enables your team to promptly address issues, maintain quality assurance, and contribute to team-wide knowledge sharing. Plus, regulations like SOC2 require rigorous control and documentation standards, so this practice will make it easier for you to adhere to and prove that you meet such regulatory controls. 7. Measure and optimize Shifting security left is not a “set it and forget” ordeal. Technologies and threats change, new tools are introduced to make your job easier, and your SDLC and application codebase scale and grow. Much like CI/CD, shift left must be a continuous process of measuring success and optimizing to match business needs and constraints. Shifting left with Jit’s DevSecOps orchestration One of the challenges with shifting security left is choosing the tools and processes to fit seamlessly into existing development operations without overburdening developers with unnecessary tools and uninformative alerts. Jit is a unique DevSecOps orchestration platform built with developer experience as a top priority. With Jit, you can create a security plan that provides only the protection your SDLC needs. A turnkey solution to automating security testing with OSS tools and none of the hassle, Jit morphs and grows to match your shift left strategy. Explore Jit to discover how to shift left security the right way. ‍

Security IaC Security Essentials: How to Code Your Way to a Fort Knox Infrastructure Infrastructure as Code (IaC) is selling like hot cakes in IT provisioning and administration. One of the core components of DevOps and the “shift left” movement, IaC enables the codification of infrastructure while reducing overhead and increasing environment consistency. The flexibility and agility it offers are unprecedented. When mistakes don’t happen in the process, that is. More than half of all successful breaches result from human error or misconfigurations. Infrastructure engineers and senior software developers are humans, too - so they’re bound to make mistakes at some point. But could the security gaps in IaC be more of a curse than a blessing for cloud-native infrastructure? Ensuring your IaC is protected from malefactors takes rigorous planning, and it starts with understanding where potential security risks lie. This article guides you through the security considerations of IaC and how you can best mitigate risks to maintain a strong-as-steel infrastructure. It’s an IaC revolution, but where does security fit in? IaC is a powerful tool for deploying, managing, and scaling complex IT processes without impacting development velocity. It offers a flexible approach that turns application infrastructure management and provisioning into something they know well - declarative code scripts. From a cloud-native application security perspective, IaC also improves the security of cloud-native deployment by solving environment drift in release pipelines. It enables consistency by replicating preconfigured templates and employing auditable version control - much like software. So, it’s no wonder that as many as 58% of IT decision-makers are adopting IaC. However, as the saying goes, with great power comes great responsibility. There are several risks to consider when adopting IaC as an alternative to manual configuration processes, including: 1. Insecure handling of code secrets Code secrets like passwords, API keys, or IP addresses of critical server systems and webhook URLs in IaC templates and scripts pose a risk if exposed to malefactors. 2. Configuration drift and “shadow” assets The security of your IaC depends on the immutability and consistency of your infrastructure. When developers directly change the infrastructure and bypass pre-deployment security scans, you get configuration drift between your environments and potentially untagged and de-facto invisible cloud infrastructure. 3. Untrusted base images and misconfigured templates To codify infrastructure, developers employ IaC templates that include base images. Base images from an untrusted source can include malware and backdoors. Moreover, IaC template code and its dependencies may contain bugs - like any code. These bugs can become security risks if not identified and remedied before deployment. 4. Human error The IaC risks mentioned above, and many more, are most commonly caused by human error rather than malice or technical malfunction. With development velocity prioritized above all else in rapid and agile development processes, it’s far too easy to grant overly permissive access to a service to speed things up or make manual changes to the production environment infrastructure. IaC Security Essentials: How to Code Your Way to a Fort Knox Infrastructure 1. Adopt DevSecOps and GitOps practices DevSecOps, a set of practices for adding a layer of security to the DevOps workflow, can help automate IaC security while minimizing interference with developer workflows. Make your infrastructure build scripts part of the codebase and treat it as such throughout your CI/CD pipeline through Security as Code. This helps you ensure that all infrastructure changes are scanned, tested, verified, and deployed uniformly and securely. Moreover, using GitOps for IaC versioning, you can track IaC configuration changes more quickly. This also creates an audit trail and enables better collaboration on IaC security issue remediation in a developer-native environment. 2. Perform IaC security scanning Automated security scanning of code and application assets in the CI/CD pipeline is one of the core concepts of DevSecOps. You can only do so much to prevent misconfigurations and security vulnerabilities from popping up in your code. However, there’s quite a lot you can do to detect these issues in the early stages of development and runtime. This entails integrating Software Composition Analysis (SCA) tools and Static Application Security Scanning (SAST) of your IaC. You can leverage battle-tested open-source tools like KICS, an IaC scanning SAST tool that can handle Terraform, Serverless Framework, Pulumi, CloudFormation, and AWS CDK output. For runtime IaC security, you can employ Prowler to scan for misconfigurations and vulnerabilities in the construction of cloud resources. Jit’s DevSecOps platform can orchestrate KICS and Prowler (and many other open-source security tools such as SCA and SAST) straight into your CI/CD pipeline. Plus, it provides developers with enriched findings for each vulnerability discovered and instant remediation suggestions for over 200 IaC misconfigurations. 3. Enforce Least Privilege and harden access management The principle of least privilege (PoLP) should be the cornerstone of your Identity Governance strategy. Following this principle requires limiting permissions to a minimum and granting access only when needed. Create strict IAM policies and continuously monitor user activity to ensure no access control gaps. You can also employ and enforce rules like key auto-rotation, temporary access roles, or Role-Based Access Control (RBAC). RBAC can help you implement mandatory and discretionary access control, restricting network access based on roles and striking the right balance between security and operational efficiency. 4. Prevent code secret sprawl Even though code secret privacy is one of the most common best practices for application development today, some secrets can still leak unintentionally and fall into the wrong hands. Another type of scan you should employ are code secret scans to ensure your IaC configuration files don’t contain potentially sensitive information like passwords and API keys. You can include open-source tools like Gitleaks in your IaC security scanning policy using the Jit DevSecOps platform. In addition, it’s worth looking into vendor services like AWS Secrets Manager and Microsoft Azure Key Vault. 5. Train your devs & prioritize IaC security The only way to minimize human error and reap the security benefits of IaC is through training and prioritization of code security on an organizational level. This requires a security-first mindset and entails bridging the operational and conceptual gaps between information security engineers and software developers. With security awareness training and proficiency in organizational security policies and tools employed, developers are better equipped to deliver safe code - including the code that builds the infrastructure. 6. Employ continuous monitoring Monitoring of infrastructure for changes in IaC template configurations can help increase visibility into your overall cloud security posture. But more importantly - continuous security monitoring tools can alert you to configuration changes and environmental drifts in your infrastructure, as well as necessary updates and patches you should apply to the third-party resources you use in your IaC setup. 7. Codify your policies Infrastructure is not the only thing you can codify to streamline operations. By using policy as code (PoC), you can define, manage, and enforce infrastructure security policies through code, enabling you to automate the implementation of organizational policies and best practices for security and compliance in your infrastructure code. IaC security orchestration with Jit Infrastructure as code enables developers to build and deploy scalable infrastructure securely. It minimizes human error and misconfigurations that stem from manual management and provisioning of application infrastructure. However, IaC introduces its own set of risks and potential vulnerabilities that can expand your attack surface. As with any type of code, the key to secure development is integrating security into the SDLC with tools that empower developers rather than overburden them. Jit is a continuous security tool that streamlines the integration of security controls throughout the DevOps workflow with a cloud-native CI/CD approach. We leverage proven open-source libraries and tools to create a developer-friendly, insight-enriched DevSecOps orchestration platform that you can get started with right away. See how it works.

Security Top 10 DAST Tools for 2024 In the quest to shift security left, it’s easy to lose track of security once your app goes live. But with cyber threats increasingly targeting live websites and apps, can businesses really afford to make post-production the end of the road for security testing? Half of security professionals admit that developers fail to identify 75% of security vulnerabilities. When such vulnerabilities make it to the production stage - a purely reactive, ad-hoc approach to security is likely to install panic among dev and security teams - and be a painfully inefficient way to address issues without causing business disruption. Enter DAST - a dynamic approach to security testing that analyzes apps in runtime, ensuring no gaps are left unattended. There are countless DAST tools available, but the last thing you need is to add yet another solution to your toolchain without understanding how it fits your DevOps team’s needs and integrates into your current stack. To give you a helping hand, we list the top 10 DAST tools for 2024 in this article, including their unique features and best use cases. But first, let’s explore DAST and what you should expect from these tools. What is DAST, and how does it work? Unlike SAST testing, which analyzes the application’s source code and related dependencies, DAST analyzes apps from the "outside-in" by simulating attacks on the application. This “black box” testing method interacts with the running application without accessing its source code, mimicking how an attacker would interact with the app in a real-life scenario. It sends automated requests and payloads to the application (similar to what a malicious attacker would do). Then, it analyzes the app’s behavior and responses, looking for misconfigurations and vulnerabilities that may lead to attacks such as SQL injections and cross-site scripting (XSS). Once vulnerabilities are found, DAST tools report their findings, which typically include a detailed overview of the vulnerability type, severity, and location to help developers address issues faster. Because this type of testing doesn’t access the source code, it is most suitable for testing apps already in production. However, it can be used across various stages of the SSDLC, depending on business needs. Adding other types of testing, such as SAST and SCA, can bolster the effectiveness of DAST testing. For instance, SCA security tools work like specialized static security testing, looking specifically into the system’s connected open-source libraries and frameworks. The more layered approach you can take to security testing - the more protected your apps are. ‍ Why would you need a DAST tool? Real-world and real-time testing: Because DAST tools simulate real-world attacks, you get real-time insights into how an application would fare against actual threats.Full application coverage: DAST tools interact with all exposed application interfaces, ensuring comprehensive coverage.Ease of use: Since DAST doesn’t require access to the source code, it is easier to use, especially across third-party applications where the source code might not be available.Detection of runtime vulnerabilities: DAST tools excel at finding vulnerabilities that only become apparent during runtime, such as authentication and server configuration issues.Scalability: These tools can be automated and integrated into the SDLC, making it easier to scale security testing efforts across multiple applications.Meeting regulatory compliance: Many industry standards and regulations, such as HIPAA, GDPR, and SOC2, require dynamic testing methods like DAST to ensure data protection and application security. The key features to look for in DAST tools You can’t cut corners when implementing DAST into your security toolchain. A good DAST tool should offer complete coverage - scanning all exposed application interfaces for vulnerabilities. Ideally, to get you from a reactive to a proactive stage, you should also be able to automate the tool for continuous scanning. This allows you to be constantly in the know, catching and resolving vulnerabilities as they arise. Ensure that your DAST tool can integrate seamlessly into your existing DevOps pipeline to help streamline your security testing process. DevSecOps platforms like Jit consolidate your security plan so you can automate and manage all your security tools and controls into one platform. Then comes the findings and reporting stage. Here, your DAST tool must provide real-time insights into the status of your applications, as well as detailed reports and remediation suggestions, so you know which vulnerabilities to prioritize and can automate an effective risk mitigation workflow that won’t cause disruption or operational overhead. With Jit, all your repos can easily be monitored, with appropriate security tools invoked to provide relevant alerts for any red flags. And speaking of red flags that aren’t actually as red as they seem (a.k.a. false positives), ensure that your DAST tool is comprehensive enough to minimize false positives, providing you only with accurate and actionable alerts. ‍ Top 10 DAST Tools for 2024 1. OWASP ZAP OWASP ZAP is a free and open-source tool actively maintained by a dedicated international team of volunteers. It provides features like active scanning, alerts, anti-CSRF tokens, authentication methods, breakpoints, and passive scanning. Best For: It suits any web app developer or security team that wants to perform security testing on their web applications. Jit can seamlessly integrate with OWASP ZAP to automate DAST testing in your CI/CD. Customer Review: "Owasp zap proxy is the best recon and penetration testing tool, which contains all things from manual testing to automation testing. For me especially, automatic testing is the best with Ajax Spider, and active scanning performs all the vulnerability tests, which is really good." ‍ 2. Jit While not specifically a DAST tool, Jit is a DevSecOps platform that orchestrates DAST tools such as OWASP ZAP and other security testing tools such as SAST and SCA across your CI/CD pipeline. It enables DevOps-oriented teams to establish and automate a security plan, making it easier to implement and manage security controls across the entire SSDLC. Jit users also get real-time remediation suggestions and enriched findings based on reports from other tools in a single dashboard. Best For: It’s best suited for DevOps teams looking to automate their security workflows and integrate them into their CI/CD pipelines. Customer Review: “I love the notion of Jit providing as-code security plans, which are minimal and viable. The fact that Jit also automates the selection of relevant security tools and unifies the experience around them is super valuable.” 3. Veracode Veracode is a comprehensive cloud-native platform that reduces risk across all modern software components, from proprietary code to APIs and Infrastructure as Code. It can scan hundreds of web apps and APIs simultaneously, providing accurate alerts that developers can delve into in its dashboard. Best For: It’s best suited for large-scale enterprises looking to secure every development phase for every application. Customer Review: "Easy to set scans to monitor risks on applications. Informative dashboards to help monitor remediations." 4. Checkmarx Checkmarx’s significant features include real-time analysis, which evaluates running apps, and timely alerts that might arise due to recent changes in the code base. It can also be integrated into existing development and security workflows. Best For: It’s best suited for organizations integrating security testing into their development process. Customer Review: “The most valuable features are the easy-to-understand interface and it's very user-friendly. Reduce the code using cxsast plugin. It will scan code line by line and find most of the vulnerabilities. Very easy to use. Vulnerability report is awesome.” 5. Spectral Although not specifically a DAST tool, as part of Cloud Guard, Spectral offers DAST testing. Driven by AI, this can strengthen your security posture and mitigate risks by making it easy for developers to uncover blindspots and detect issues as early as the pre-commit stage. Best For: It’s best suited for organizations leveraging AI-driven models and tools for on-chain risk solutions and those needing DAST testing as part of their security measures. Customer Review: “We've solved the issue of having zero visibility into our ADO environment with SpectralOps. It integrates easily into ADO, allowing us to track down exposures we previously had no knowledge about.” 6. Acunetix Acunetix provides dynamic application security testing against various web application attacks to identify vulnerabilities and assess their behavior. It features a fully automated crawler that can crawl complex custom HTML5 websites and web applications, including client-side single-page applications (SPAs), making it easier to implement zero-trust security. Best For: Acunetix fits organizations looking to integrate security testing into their development process. Customer Review: "It assists in identifying and repairing website flaws, reducing the likelihood of attacks and data theft. The scanning tool is extremely intelligent and can identify even the most complex security issues." 7. AppCheck AppCheck offers in-depth automated testing for ad-hoc, scheduled, and continuous security testing. It provides full OWASP vulnerability coverage, including injection, XSS, RCE, zero days, plus 100,000+ known security flaws. Best For: AppCheck is best suited for organizations that require robust and comprehensive security testing integrated into their development process. Customer Review: "We used to have a manual pen test, used the free trial to compare, and AppCheck blew it out of the water. Then it occurred to me that manual testers just use automated tools anyway, so why not save time and cost.” 8. Intruder Intruder’s web app vulnerability scanner crawls through a site or app, looking for vulnerabilities and security flaws. This solution lets you assess your risk level and helps you prioritize remediation efforts based on the severity of detected vulnerabilities. ‍Best For: Intruder works best for organizations that want a user-friendly platform for managing attack surfaces and automating vulnerability scanning processes. Customer Review: "This platform enables my team not to waste time testing against known vulnerabilities and focus on hardening our services and solutions. Intruder also provides a huge benefit in proactive Change detection, where it will advise when new instances or hosts are detected and any vulnerabilities it may have, allowing for more agile change management.” 9. SOOS SCA + DAST SOOS SCA + DAST combines SCA and DAST in one platform. You can simultaneously use the features of SCA - such as finding and fixing open-source vulnerabilities - and DAST, which scans your web apps and APIs based on OpenAPI, SOAP, or GraphQL standards. The combined dashboard makes continuous monitoring, license issues, and policy violations accessible in a single interface. Best For: It is best suited for organizations that require both Software Composition Analysis (SCA) and Dynamic Application Security Testing (DAST) in one platform. Customer Review: "With the integration we have in our pipelines, the ability to provide continuous assessment of software security as changes are made to the application and new dependencies are added has been very useful. Additionally, SOOS has been of great importance for our certification processes (Hitrust, SOC2).” 10. Detectify Detectify is a cloud-based EASM platform specializing in surface monitoring and application scanning. The automated discovery and continuous monitoring features help DevSecOps teams discover and remedy vulnerabilities easily integrated into Slack, Jira, and Splunk workflow tools. Best For: Detectify is best suited for organizations that want a user-friendly platform for managing attack surfaces and automating vulnerability scanning processes. Customer Review: "From the discoveries of new subjects, and for the ease of use, I also really like the integration of notifications and detailing the vulnerabilities and how to perform their corrections." Securing every part of your application - at every stage DAST tools support a proactive approach to identifying vulnerabilities, ensuring that web applications can withstand increasingly complex and dangerous cyberattacks. While essential to production environments, they are just one piece of the puzzle - and must be added to an end-to-end security plan and toolkit that covers each stage of your SDLC. If you want to combine development, security, and operations seamlessly, Jit can weave security checks into your CI/CD process, making security more comprehensive and automated than ever. Start for free here.

Development A Step-by-step Guide to Preventing Dependency Confusion Attacks Third-party dependencies have become more than just a tool – they are the backbone of modern software development. Using them, you can push the boundaries of innovation, simplify your workflows, and leverage the genius of others through pre-built solutions. But, as with most good things, there's a catch. As you integrate these external components, you also open the door to potential security vulnerabilities lurking just out of sight. Supply chain attacks aimed at libraries and other development tools are up by an astounding 633% year-over-year. Among these, the popularity of dependency confusion is rapidly climbing the ranks, posing a formidable challenge to the very efficiencies these dependencies promise. You could say the industry has a bit of a dependency problem. This article explores how these attacks exploit the trust developers place in package managers and public repositories and, more importantly, provides a comprehensive guide on how to fortify your software supply chain against such threats. What is a Dependency Confusion attack? Dependencies are external software libraries, modules, or packages a software application integrates with to achieve specific functionalities. These dependencies are typically sourced from public repositories or package managers, allowing developers to leverage pre-existing solutions and streamline the development process. Unfortunately, leveraging these public repositories could expand your cyber attack surface, as their open and collaborative nature makes them more prone to cyberattacks. One such attack is the “dependency confusion.” First identified by Alex Birsan, dependency confusion is a relatively new and novel attack within the application security world. Some package managers will look to private and public repositories when resolving a dependency. If they find packages with the same name in both repositories, they might prioritize the one in the public repository, especially if it has a higher version number. Attackers can exploit this behavior. There are three primary vectors for executing a dependency confusion attack: Namespacing – By exploiting how package managers handle namespaces, an attacker can create a package in a global namespace that conflicts with a package in a scoped or private namespace. DNS Spoofing – DNS Spoofing attacks can happen when the package manager fetches dependencies over an insecure channel. Attackers can perform a Man-in-the-Middle attack, redirecting the request to a malicious server. The malicious repository will appear to have a legitimate URL. Scripting – By tweaking build scripts or messing with CI/CD security settings, attackers can trick systems into sourcing dependencies from a malicious repository. How Dependency Confusion attacks work Dependency confusion attacks exploit software developers' trust in package managers and public repositories. A typical dependency confusion attack may unfold as follows: Reconnaissance – At the outset, the attacker surveys the app to pinpoint target dependencies by examining manifest files (like package.json for JavaScript projects or pom.xml for Java projects) that are sometimes inadvertently exposed or leaked. Attackers may also scour code repositories and network traffic to try and identify the names of private packages that the application relies upon. Creating a Fake Malicious Package – The attacker then publishes a package with the same name to a public repository but with a higher version number. This fake package contains malicious payloads or backdoors within the package's codebase. These embedded elements are typically obfuscated or concealed to avoid immediate detection by static code analysis tools or manual reviews. Publishing the Malicious Package – The attacker then uploads this malicious package to a public repository. They often assign it a higher version number than the legitimate private package, making it appear as an "update" to the genuine package. Malicious Code Execution – The attack's crux occurs during the target application's build or deployment process. When the package manager attempts to resolve and fetch dependencies, it gets deceived by the versioning trick and pulls the malicious package from the public repository. Post-installation scripts embedded within the package may then be automatically executed. Exploitation – With the malicious package integrated into the application, the attacker can exploit the embedded vulnerabilities. This exploit ranges from unauthorized data access, system control, or even using the compromised system as a launchpad for further attacks within the network. 7 Tips to Prevent Dependency Confusion Attacks 1. Implement Strict Naming Conventions Adopt a standardized naming scheme for all internal packages by using company-specific identifiers, detailed descriptors, and a systematic versioning approach. For instance, a naming structure such as “orgname-functionality-version” can offer clarity and reduce the chances of mistakenly integrating an external package with a similar name. In the context of package management systems like npm, it's beneficial to proactively reserve specific namespaces that align with your organization's identity. However, you will need a different strategy for platforms like PyPI, which currently lack a namespacing feature. Here, it's advisable to preemptively claim or "namesquat" the titles of your private packages in the public domain. 2. Proactive Monitoring and Dependency Scanning Embed continuous dependency scanning and monitoring mechanisms like Software Composition Analysis (SCA) tools within your CI/CD workflow. With Jit, you can easily activate robust SCA tools, such as Npm-audit, OSV-scanner, and Nancy, directly within your GitHub environment. You can automate these tools to run on a recurring schedule and manage them within a single dashboard, getting enriched reports and real-time remediation suggestions for every new vulnerability. Remediation is available in Pull Request or via Jit’s Actions page, as shown below. In this case, you simply click the “Create a Fix PR” button, which will generate a new Pull Request and introduce the fix code so you can apply the fix in your GitHub environment. 3. Use Private Package Repositories Opt for private repositories with stringent data access controls where only specific roles or individuals with the appropriate credentials can access, upload, or modify the packages. These repositories should enforce multi-factor authentication (MFA). Popular options for private repositories include GitHub Private Repositories, GitLab Private Repositories, Nexus Repository OSS, JFrog Artifactory, Docker Hub Private Repositories, and Bitbucket. These platforms offer enhanced security features tailored to organizations prioritizing code and package security. 4. Enforce Package Whitelisting Incorporate strict package allowlisting mechanisms within your CI/CD pipeline. Automated tools or scripts can scrutinize every dependency introduced or updated during the build phase. These tools should cross-reference each package's name, version, and possibly its checksum or digital signature against a pre-defined approved list. If a package doesn't match the criteria or isn't found on the allowlist, the CI/CD pipeline should immediately flag it and halt the build or deployment process. This interruption is a protective measure, so potentially harmful or unvetted packages don't make their way into the production environment without a thorough manual review. 5. Implement Strong Access Controls Adopt a robust access control strategy by integrating Role-Based Access Controls (RBAC) within your package management and repository infrastructure. Doing so lets you define specific IAM roles and assign granular permissions associated with each function. For instance, you can restrict package publishing or modification rights solely to senior developers, DevOps teams, or other trusted personnel. Junior developers or external contributors might only have read access or require multi-factor authentication for specific actions. This hierarchical access model shields critical packages from malicious changes, which reduces the risk of introducing vulnerabilities or compromised dependencies into the codebase. Detailed access logs can also help you swiftly detect and address any unusual or unauthorized activity. 6. Package Signing and Verification Embrace cryptographic measures by signing your packages using private keys. This process embeds a unique digital signature within each package, acting as a seal of authenticity. When the package is fetched or integrated into an application, its embedded signature should be cross-verified against a trusted public key corresponding to the private key used for signing. This practice also deters attackers from introducing rogue packages or tampering with existing ones, as any such attempts would break the signature validation. 7. Version Locking Leverage the power of lock files to maintain consistency and security in your dependency management. Files such as `package-lock.json` in the npm ecosystem or `Gemfile.lock` in the Ruby world are snapshots of the exact versions and configurations of dependencies your project relies on. By locking down specific versions, you prevent the accidental introduction of newer versions of packages that might contain vulnerabilities or untested changes. Version locking is especially crucial when specific packages might introduce breaking changes or when more recent versions haven't undergone rigorous security vetting. Lock files also provide a clear record of which versions of dependencies are in use, making it easier to audit, review, and roll back if necessary. Safeguarding Your Digital Assets As we've seen, dependency confusion attacks are a lurking threat. Companies often harbor a false sense of security regarding their third-party dependencies. However, today's risk landscape requires a serious, zero-trust approach. This means that even open-source components must be verified as secure, continuously monitored, and updated regularly. Jit’s DevSecOps orchestration platform helps you confront these dependency challenges. With its intuitive tools and real-time insights, Jit seamlessly integrates into your CI/CD pipeline, ensuring your software's defenses are always up-to-date. Activate powerful SCA tools like npm audit, OVS Scanner, and Nancy to fortify your software like never before. Explore more here.

Security 6 Essential Steps to Use OWASP ZAP for Penetration Testing There's no doubt that no organization wants to be the victim of a cyber-attack; however, in practice, even the most security-minded organization can find itself caught off-guard or exposed when a zero-day exploit is discovered. In addition, with the complexity of our systems (apps, networks, and websites) and increase in various vulnerabilities discovered daily, it's becoming harder and harder to stop them all. Despite our best security efforts, this can open the door to malicious users. We don’t need to paint the horror story of what a cyber attack costs a company in business, trust, reputation, and much more - but it’s in the millions and billions of dollars at times, and many man hours to mitigate and remediate the attack. ‍ Today, we are much more well-positioned to overcome security challenges, with many excellent open-source security tools, knowledge, and awareness to support better security hygiene. One excellent tool that has been a game changer for simplifying security detection and ultimately remediation is OWASP ZAP (a tool we have spoken about many times and love). For those who haven’t read our previous posts (you should!). OWASP ZAP is an open-source community project that provides great out-of-the-box DAST for your web apps. In our previous posts, we provided some tutorials for getting started and testing permissions policy header configuration. This article will take you through all the steps to use OWASP ZAP for penetration testing to effectively protect your systems. Types of Security Testing In our previous posts, we discussed the different kinds of scans available. In this post, we'll focus on the actual testing. As security continues to evolve, so too, do the methods used to test the security of systems and networks. Security testing is more necessary than ever to identify vulnerabilities and have a real-time understanding of the risks posed to your organization through its code and systems. This is where continuous security comes in. With the many diverse technologies in our stack, to stay ahead of would-be attackers, we can employ different types of scans and tests to get the most coverage for our stacks. Below are some of the most popular types of security testing: Vulnerability assessment: A vulnerability assessment analyzes a system or application to identify security risks. It is essential because it can help to prevent attacks by identifying and fixing security vulnerabilities. A vulnerability assessment can be used to safeguard a business by identifying potential security risks and taking steps to mitigate them.Penetration testing: Penetration testing is a type of security testing that is used to assess the security of a computer system or network. It is used to find vulnerabilities that attackers could exploit.Runtime testing: Runtime testing is a process of testing software during its execution. This type of testing can reveal errors that may not be apparent during design or compilation.Code review: A code review is a process where code is inspected for potential errors, vulnerabilities, and compliance issues. It can be used to safeguard your business from malicious attacks by identifying and correcting errors and vulnerabilities before cyber attacks can exploit them. Code reviews can also help ensure compliance with industry and government regulations. What is Penetration Testing? The purpose of penetration testing is to identify security vulnerabilities that attackers could exploit to gain access to sensitive data or systems. It can help a business protect against bad actors by identifying security weaknesses and providing recommendations for improving the organization's security posture. The 5 Penetration Testing Stages ‍ Phase 1: Planning and Reconnaissance Planning and reconnaissance is the first step in penetration testing. It helps the tester understand the target environment and identify potential vulnerabilities. It also allows the tester to create a plan of attack and choose the appropriate tools and techniques for the test. Phase 2: Scanning The scanning stage is the process of identifying the systems and services that are running on a network. It allows the penetration tester to determine which systems are vulnerable and which are not. The scanning stage also allows the penetration tester to choose the best way to attack the systems on the network. Phase 3: Gaining System Access In this phase, the attacker tries to gain access to the system. This can be done by attempting to exploit vulnerabilities in the system, brute forcing passwords, or social engineering. This stage is crucial because it is when the attacker can gain access to the system and start to compromise it. Phase 4: Persistent Access The Persistent Access stage in penetration testing is where the attacker attempts to maintain access to the system after the initial compromise. Persistent Access can be done through some methods, such as installing a backdoor, setting up a persistent reverse shell, or adding a user to the system with elevated privileges. This stage allows the attacker to maintain a foothold on the system even if initial access is lost. This can impact your business by enabling the attacker to monitor your system continually and collect sensitive data or launch further attacks against other systems. Phase 5: Analysis and Reporting The analysis and reporting stage in penetration testing is when the pentester analyzes the data gathered during the assessment and creates a report detailing their findings. This stage allows the pentester to communicate their findings to the client to take appropriate action to mitigate any risks. It is also vital for businesses to understand the potential impact of any vulnerabilities found to make informed decisions about how to protect their systems. Below we’ll dive into how you can leverage OWASP ZAP to automate this process and continuously run this process with minimal friction to have an ongoing understanding of the evolution of your security posture. How to use OWASP ZAP for Penetration Testing ZAP is short for Zed Attack Proxy, which is leveraged by many pentesters to find security vulnerabilities in web applications, understand and fix security issues, and maintain long-term security hygiene. It does this by creating a baseline security assessment of a web application, and helps ensure compliance with security standards and regulations. Without further ado, let’s get started with the quick guide on how to use OWASP ZAP for penetration testing. 1. Installing ZAP You can download the latest version from the OWASP ZAP website for your operating system to install ZAP or reference the ZAP docs for a more detailed installation guide. ‍ Once completed, follow the prompts to install OWASP ZAP on your machine. 2. Persisting a session Persisting a session in OWASP ZAP means that the session will be saved and can be reopened at a later time. This is useful if you want to continue testing a website or application at a later time. Once you’ve started OWASP ZAP, you will see a screen that looks like this: The prompt gives two options to persist in the session. You can use the default to name the session based on the current timestamp or set your name and location. Alternatively, you can persist a session by going to ‘File’ and choosing ‘Persist Session…’. Give your session a name and click on the ‘Save’ button. 3. Running an automated scan Running an automated scan in OWASP ZAP is a way to check for common security vulnerabilities in web applications. This is done by sending requests to the application and analyzing the responses for signs of common vulnerabilities. It can help to find security issues early in the development process before they are exploited. With OWASP ZAP, you can use a ZAP spider or the AJAX spider. So what’s the difference? ZAP spider is a web crawler that can automatically find security vulnerabilities in web applications. Meanwhile, the AJAX spider is a web crawler designed to crawl and attack AJAX-based web applications. Clicking on the ‘Tools’ option will give you a list of available pentesting tools provided by OWASP ZAP. To run an automated scan, you can use the quick start “Automated Scan” option under the “Quick Start” tab. Enter the URL of the site you want to scan in the “URL to attack” field, and then click “Attack!”. 4. Interpreting test results Interpreting test results in OWASP ZAP is vital to understand the scan findings and determine which issues require further investigation. Additionally, it can help to prioritize remediation efforts. In OWASP ZAP, you can view alerts by clicking on the "Alerts" tab. This tab will show you a list of all the alerts that have been triggered during your testing. The alerts are sorted by risk level, with the highest risk alerts at the top of the list. OWASP ZAP will give details of the discovered vulnerabilities and suggestions on how you can fix them. 5. Viewing alerts and alert details Viewing alerts and alert details in OWASP ZAP is a way to see what potential security issues have been identified on a website. It can help security and administrators understand what needs to be fixed to improve the app's security. If you cannot find your ‘Alerts’ tab, you can access it via the ‘View’ menu, along with other options available in OWASP ZAP. Once you have your ‘Alerts’ tab, you can navigate the various vulnerabilities discovered and explore the reports generated by OWASP ZAP. 6. Exploring an application manually Exploring an application manually in OWASP ZAP is a process of manually testing the application for security vulnerabilities. It is done to identify any potential security risks that may be present in the application. Doing this can help ensure that the application is as secure as possible. The manual scan complements the automated scan by providing a more in-depth analysis of the application and allowing you to navigate the pentest process. The automated scan may miss some vulnerabilities, but the manual scan may pick up missed issues. However, the manual scan can be time-consuming and may not be feasible for large applications. To explore an application manually, select “Manual Explore.” Select your browser, and OWASP ZAP will launch a proxy in your browser. Here, you will be given pentesting tools such as spiders, and if a vulnerability is discovered, an alert flag will be added to the alerts panel. Where to from here? Having a developer perform a pentest with OWASP ZAP is one way to do a security audit. However, with anything manual, efficiency is often lost. This is where Jit comes in. We know that pen testing is essential, but it can be cumbersome, mainly if your development team is already preoccupied with finishing features and needs to release the next cycle of updates for your applications. In addition to this, OWASP ZAP only covers one part of the pipeline. With Jit, your team can quickly assess all the security knowledge and tools needed to identify areas for improvement across all stages of the development process. Security doesn’t have to be the last port or forgotten thought. It doesn’t matter where in the pipeline; Jit has you and your team covered for all things continuous security get started today.

Top 20 Best VScode Extensions for {year}