staging-devopsy.kinsta.cloud

Tag: devsecops

  • Improving Security with Mapping, Automation and DevOps

    Improving Security with Mapping, Automation and DevOps

    Strong cybersecurity is paramount for every organization. But all too often, security teams are disconnected from ongoing development processes and viewed either as an impediment to bringing products to market or as an afterthought. This leads to increased costs and possible gaps in the attack surfaces of new platforms.

    While many organizations are turning to security automation to help them manage and mitigate their expanding threat landscape, quick fixes rarely work. Planning is required to help organizations determine their pain points, add security early in the software development process, and determine where automation can deliver the best ROI.

    What Should Be Automated?

    Security automation can programmatically test, institute guardrails, provide feedback and remediate cyberthreats by executing tasks as part of the continuous improvement pipeline. This, in turn, can help understaffed security teams by streamlining complicated and time-consuming testing processes, enabling teams to maximize their time, be more productive and focus on risk priorities. Once the manual process is removed, the automated workflows can then carry out a variety of more minute actions using intelligence and logical decision-making.

    Security-focused areas that may benefit from automation technology include but are not limited to:

    • Static and dynamic code analysis used to discover security vulnerabilities
    • Test harnesses for software configured to run a program unit under varying conditions to discover and monitor its behavior and outputs
    • Upstream code analysis that examines code such as complete code blocks or patches
    • Vulnerability testing, management and remediation to discover and fix weaknesses that may be susceptible to attacks
    • Penetration testing used to simulate cyberattacks on an organization’s computer systems and evaluate security posture
    • Automated enforcement based on data classification and tagging strategy
    • Deployment and management of infrastructure components

    Focus on ROI

    Despite the benefits, many organizations face substantial hurdles in developing, implementing, testing and optimizing the comprehensive, integrative, long-term approach needed to use security automation to cope with the evolving threat landscape. It’s all too common for organizations to begin projects that start with automation as the outcome rather than rigorously mapping the processes and determining where value from automation can be gained.

    Consider an organization that decides to automate the process of deploying a firewall to an AWS cloud. A team spends several weeks developing and testing an automation playbook that can spin up virtual firewalls, license them, connect them to a central manager, deploy configurations and apply them and send logs to the appropriate places. Testing proves the automation works.

    But when asked how many firewalls they expect to spin up this year, the answer is two–maybe. How many next year? None. The team, therefore, spent more time automating this function than it would have taken to just deploy the systems and the organization won’t likely realize any direct return on this work for at least two years.

    Value Stream Mapping

    The first step in achieving real value is to understand that automation is a second-order operation that relies on a thorough assessment and plan of all the steps required to achieve real technical and business outcomes. That means conducting value stream mapping to analyze, design and manage workflows that best suit your environment.

    Mapping will help you analyze and define security processes. Without analyzing your processes, you’ll have no idea of where the bottlenecks are or how they can be removed. Better understanding the processes will also allow you to refine them as needed. Without doing all this, you’ll have no way to prove the value of the automation you’re implementing, and no compelling business justification for it.

    The Role of DevOps

    Few organizations are able to effectively realize the benefits of automation right out of the gate. Value stream mapping enables organizations to determine their pain points, pinpoint exactly where they want to use automation and identify processes that cannot or should not be automated. Clear-eyed planning and assessment will help teams define a process and determine the value of return on automating certain processes.

    In addition, for security to be effective, we have to shift security left in the software development life cycle (SDLC). Security practitioners should be engaged in the development pipeline, including collaborating on automation initiatives and building harness and test cases as the work progresses. This will save time, improve quality and ultimately add value, ensuring the success of security automation projects.

  • Accelerate Your SDLC With DevSecOps

    Accelerate Your SDLC With DevSecOps

    DevOps has been the answer to rising software development complexity, but the granularity and multiplicity of actors, technologies and environments brings added security requirements. Moving to DevSecOps will not only help with these requirements but also accelerate the software development life cycle (SDLC).

    As development projects mature, more developers get involved, the code base grows and architecture becomes more complex; consequently, the SDLC slows down. This is why Agile, microservices and DevOps have emerged—to solve this specific problem by separating big teams into smaller ones and monoliths into more nimble components.

    But this granularity and multiplicity of teams, work environment, technologies, services and repositories makes integrating security even more complex. In fact, developers now face multiple SDLCs and often, the gains achieved in velocity can be nullified by security issues. You want a process that works, and preferably, a process that works fast.

    This is what DevSecOps attempts to solve; adding security into DevOps actually accelerates the SDLC. Here’s why and how.

    DevSecOps During the Planning Phase

    The planning phase is key as it answers essential questions at the time when architectural decisions are made. Some of these decisions are relative to access control, network infrastructure and data security. For each, adding automation—and therefore, security—allows fast replication.

    For access control, you can leverage infrastructure-as-code (IaC) tools (Terraform, for example) to easily define different groups, roles and permissions with code. By adding various plugins, you can even use your IaC tool to manage users on other platforms, as in GitHub. When you have all the groups, roles and permissions defined as code, you are only one commit away from access control updates.

    If you need to onboard a new team member not only to, say, a specific AWS group but also to a GitHub group, instead of doing it manually in two places, you can do it “as-code” to both with minimal changes.

    The complexity of organizations and the need for better security implies the need for more role-based access controls, but automation tools exist, and they are also less error-prone.

    When it comes to network infrastructure, you can also use IaC, but you will also need to add a security layer on top of it to mitigate any errors in the code. As an example, you can use tfsec and terrascan on Terraform. This will scan your code statically and, based on predefined rules, generate alerts and give you advice on improving your security. If you prefer CloudFormation, use cfnlint, which even allows you to define your own security rules.

    When you have your infrastructure ready, the next big thing to think about is your data. You need to put data encryption in place to make sure data is securely stored at rest. You also need to add transport layer security (TLS) for the databases to secure the traffic in transit. Besides using static code analysis tools and ready-to-use services, you can even automate your own pipeline. This is very useful when you have multiple agile teams.

    Let’s take S3 buckets as an example. You could build a generic solution where the S3 event triggers a serverless function that checks the bucket’s permission. If a policy is violated, it can be fixed right away and the owner notified automatically.

    Moving to Development

    During the development phase, you need to address three major security areas: Code repository security, continuous integration (CI) security and container image security.

    Code repository security needs to address questions around the repository access control, considering the principle of least privilege but also checking that no repository is made public by accident or that they do not contain sensitive elements, such as secrets.
    With a multi-team, agile and microservices setup, you need automation to skip time-consuming and error-prone tasks but also to avoid slowing your SDLC to a crawl. We already mentioned git user management automation, but there are also a number of tools for static code analysis and secrets detection. You can even include this detection in your CI pipeline and integrate it with your alerting workflow to eliminate the risk from the origin.

    CI security is often overlooked, but this is a very important element; if your CI is not set up correctly it can generate data leaks. Access to your CI needs to be controlled to give the proper permissions and access rights. Doing this manually will definitely impact your SDLC velocity so, again, there’s a need to automate. You can integrate your CI with your Git or company single sign-on (SSO) solution for authentication. For authorization, you may rely on the groups’ information provided by those SSO services.

    Secrets are also critical for CI. Modern CI pipelines allow you to store secrets at a project level. Once configured, you can use it directly in the build without putting the sensitive data in clear text format. Even if you try to print the variable containing sensitive data, it will not show up. For instance, to use secrets directly from a Jenkins pipeline, you can store your secrets in a Kubernetes cluster and use Kubernetes Credentials Provider or HashiCorp Vault Plugin.

    Now, let’s talk about containers. While containers have simplified the deployment, scaling and failover capabilities within the SDLC, they also introduce some challenges. If the container image has some known vulnerabilities, your containers could be exploited, and the integrity of the whole machine—or even the entire system—can be compromised. Automation is, again, the go-to solution to ensure the images you build don’t contain vulnerabilities. Some CLI-based tools like Trivy can be easily integrated into your CI pipelines.

    Automation will significantly reduce your operational overhead. No more managing machines (physical or virtual), no more configuration management, no more patching. If everything is automated, that means less toil—and that means all means your SDLC is not only more secure but also faster.

    Integration and Deployment

    Kubernetes (container orchestration) is the current solution to streamline integration and deployment in our agile world. But Kubernetes is a complex system and comes with its own security challenges, of which the most important is secrets.

    The worst thing you could do is define secrets in YAML files and store them in Git repos. You could use Kubernetes’ secrets as the single source of truth, but what about secrets created by people who don’t need access to Kubernetes? This is where a secrets manager is a good choice: It acts as a single source of truth to store your sensitive data. You will get an automated process that eliminates the toil of manual labor but also guarantees security and speed.

    DevSecOps for Incident Response

    Incident response playbooks are a crucial component of DevSecOps. Playbooks are a set of generalized and summarized processes that provide a consistent way of handling issues for quicker response and resolution. Learning from every incident is also part of the playbook, whether it’s a security issue or a new vulnerability.

    The content can include everything from runbooks and checklists to templates, training exercises, security attack scenarios and simulation drills. The goal is simple: A set of policies, processes and practices for quickly responding to and resolving unplanned outages, thus helping teams fix online issues more quickly to reduce the size of the blast radius.

    We have only scratched the surface of security automation capabilities and their potential impact on the SDLC. But it’s clear that adding (automated) security into DevOps has a positive impact on the overall velocity of the SDLC and, of course, on its security posture.

  • 12 Ways to Bake Security Into a DevOps Transformation

    12 Ways to Bake Security Into a DevOps Transformation

    Security has become an integral part of any DevOps transformation. According to the Upskilling 2021: Enterprise DevOps Skills Report, DevSecOps achieved a must-have percentage vote of 56% in the automation tool category. Security not only protects the business and its customers, but it enables companies to enforce internal and external policies. 

    While considering how to bake security practices into a DevOps transformation, I asked several speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors to weigh in with their thoughts. Here’s what they shared: 

    Sponsor, Kendall Miller, president, Fairwinds

    “A DevOps transformation is about building great tooling so that developers can own their services all the way into production. The addition of security is the same thing; it’s building great tooling so that developers can also own the security posture of their services all the way through to production. This transformation is about enabling developers to understand security concerns at the application level. Service ownership is still service ownership—ownership of the operational and security pieces.”

    Sponsor, Guy Eisenkot, VP of product, Bridgecrew by Prisma Cloud

    “The key to a strong DevOps transformation that keeps security at the forefront is selecting and leveraging tools and processes that lend themselves to automation for your specific stack. For AppSec and cloud security alike, automation is the name of the game. But automation is only as strong as the processes it can fit into and the feedback it provides. 

    Security feedback will be futile if it’s not actionable and not given at the right time or in the right place. When undergoing a DevOps transformation, it’s important to keep that in mind when implementing tools and processes. It’s also important that the feedback surfaced is actionable and useful so that engineers can actually learn from and implement secure coding practices.”

    Sponsor, Rob Cuddy, global application security evangelist, HCL Software DevOps

    “The best place to start is with design and make sure that your epics, stories, hill statements and use cases all have security elements as part of them.  A great idea here is making ‘misuse cases’ or adversarial use cases and then testing against them.  For example–a misuse case might read, ‘As a bad actor, I can use a malformed URL to gain unauthorized access to a web server,’ or ‘As a bad actor, I can impersonate an endpoint in a transaction and both send and receive data while impersonating without the other parties’ knowledge.’

    It is also vital to have great SCA–software composition analysis. You cannot secure what you don’t know you have, and this includes open source and third-party tools. In a lot of cases, simple code sharing can inadvertently cause dozens of new dependencies to be added in, and those dependencies can add new vulnerabilities.

    It is important to have security aspects tested and validated throughout a pipeline, but particularly at any points in the pipeline where other checks are also being made. A great place to combine this is in QA and wherever functional testing is being done.  Leveraging interactive security testing (IAST) in an environment like this allows for monitoring to occur and for vulnerabilities to be found while application capabilities are being tested.  This greatly reduces the appearance of false positives and provides real-time information about the security posture of applications.”

    Sponsor, Yasser Fuentes, cloud workload security technical product manager, Bitdefender

    “In short, security should not just be considered at the CI, dev and test phases or limited to vulnerability assessments, since most of the vulnerability scanners and assessment tools DevOps teams use today to go over their CI/CD pipelines rely on either known vulnerabilities, signatures and known attack techniques. As a recommendation, we should emphasize the importance of incorporating tools or solutions which allow developers to identify potential threats and security flaws at the runtime level and which provide visibility beyond the typical anti-malware alerts to suspicious and potentially anomalous process-related behavior.” 

    Sponsor, Joni Klippert, co-founder and CEO, StackHawk 

    “To bake security practices into a DevOps transformation, teams need to reimagine how security plays in the software development life cycle. For many organizations today, security testing blocks applications from being shipped into production or tries to play catch-up once software is released. But it doesn’t have to be that way. 

    Security can (and should) live throughout the pre-production phases of software development. Modern security tools automate security testing in the IDE or CI/CD pipeline, alerting engineers if they have introduced a vulnerability or a vulnerable dependency.

    Making security just another type of test that is run in pre-production means teams can find vulnerabilities faster, remediate on the fly and, most importantly, get back to feature development. Baking security into the DevOps pipeline is what all teams should aim for!”

    Stephen Walters, sales engineer, Everbridge

    “The exact same way that any other practice has become baked in as part of DevOps—by following the CALMS principles. Implementing a culture of inclusion and acceptance; integrating automation into security testing, monitoring, builds and repository management; ensuring the flow and feedback of security into delivery and support is performed in a lean way, adding value and not waste; measuring security as a business value through the use of scorecards and as a success criterion for the business; sharing concerns, lessons learned, new practices and techniques.”

    Dheeraj Nayal, global community ambassador & region head – Asia Pacific, Middle East and Africa region, DevOps Institute

    “A proactive approach is the best method for building in the essentials of DevSecOps. This can be achieved by following some best practices.

    1. Teams should be aligned and in-sync
      The first and foremost step in implementing a DevSecOps culture is to train your teams that security is a shared duty of teams from all three systems. Once development and operations units take on the distributed responsibility of guarding code and infrastructure, DevSecOps becomes a routine part of the development cycle.  
    2. Keep the code simple
      Complicated code can carry more security vulnerabilities. And simple code is more comfortable to collaborate on. All your developers should be capable of looking at each other’s code and know what is happening.
    3. Testing
       SAST (static application security testing) is a key security tool that checks security issues regularly and earlier in the development process which enables it to address the issues more efficiently.
    4. Deployment
      To expedite product delivery and add flexibility to the development process, automated deployments are great. One can review properties across the IT infrastructure and implement secure configurations in a system employing an infrastructure-as-code tool.   
    5. Operations
      Operations teams must collude with security practitioners. They are accountable for controlling infrastructure and network arrangements. Operations and security teams unite to set up manual and automated security tests to warrant compliance with network configurations.”

    Peter Maddison, founder, Xodiac Inc.

    “Two main places: within platform engineering to enable the collection of the data you will need for creating visibility, feedback and learning. Next, it is important to engage the security and compliance teams to determine where you can integrate into existing standards or where modifications might be required.”

    Mark Peters, technical lead, Novetta

    “Security practices can be baked in through the standard DevOps approach, through people, processes or technology. Baking in practices with people means getting folks on the ground with your team who can advocate for security. This can happen through having your security experts spend time with the teams, assigning security to be responsible for teams, or even by selecting champions within those teams who regularly interact with security. The first agile principle, after all, is ‘people over process.’

    That component does not allow one to ignore the process.  Building the correct process implies using test-driven development at the start. Every delivery should be tested and those tests should include security testing. Some common security testing, such as code quality, now occurs so frequently many no longer consider it a separate security practice; merely a routine part of development.

    Finally, one can bake processes in through technology. Many security tools allow shortcutting through metrics, logs and traces relayed on the dashboard. These tools evaluate and highlight where security challenges occur. Tools allow integration through infrastructure and maintaining awareness of what functions occur and when. One of the old military strategies uses the OODA loop by John Boyd: observe, orient, decide and act. Just as with intelligence systems in the military, better awareness of your system through dashboards allows one to observe functions within the network, orient against possible problems, decide on a solution and act before those problems ever reach critical mass.”

    Supratip Banerjee, solutions architect, Principal Global Services

    “There are a few ways we can bake security into DevOps:

    1. Security as a mindset: There is a thought process that security in the development process might slow it down. But we must educate teams that the time and effort it takes to fix a security flaw early in the process is lower than doing it later.
    2. Platforms/environment: Proper configuration/sanitation of deployment platforms/environments is extremely important. Infrastructure-as-code (IaC), configuration-as-code, compliance/policy-as-code, secrets management, etc. can help with the process. Increased use of containers and cloud platforms can keep it clean as underlying infrastructures are managed by the provider.
    3. Automation: Include a lot of automation testing in the CI/CD pipeline. Also add static code analysis, third-party testing, AVA testing, code vulnerability checking, container security, intrusion detection and prevention, APM, etc. as automated processes. Make change management, auditing, etc. regular and as self-operating as possible.
    4. Secure architecture: Make sure security is enabled at the time of the software architecture/design phase. An architecture risk assessment must be a mandatory process to catch any design vulnerabilities before development starts.
    5. Culture of curiosity: Create a culture that emphasizes the importance of security, so everyone is interested and ready to discover if anything goes wrong with security in their system.”

    Amiran Alavidze, director of security and risk management, Tasktop

    “DevSecOps is about culture and enablement and making software delivery teams autonomous and efficient. Training and awareness is a core component of that enablement. This also includes focusing on tools that are developer-friendly and automated so that critical security controls are an inseparable part of how things are done, and allows development teams to take on all the responsibility, without a cognitive overhead of expert-level understanding of the security domain.”

    Sharath Dodda, IT development manager, TD

    “By engaging security early in DevOps with as much automation as possible. All the scans that are possible and relevant should be done well in advance in the pipeline, so that the artifact is cleared of all the findings.”

    Learn more about DevSecOps and similar topics, by registering for an upcoming SKILup Day. Or, start your upskilling journey by learning more about the benefits of DevOps Institute membership. 

  • WhiteSource Tool Automatically Fixes Code Vulnerabilities

    WhiteSource Tool Automatically Fixes Code Vulnerabilities

    WhiteSource today announced that it has developed the first-ever tool that automatically remediates vulnerabilities discovered in custom code.

    Rami Sass, WhiteSource CEO, said WhiteSource Cure surfaces recommendations for fixing security vulnerabilities in code that developers can then apply with a click of a button. WhiteSource has a long history of providing tools that discover vulnerabilities in open source software that it tracks via a database it manages, but Sass said customers are making it clear they need a way to automatically remediate those issues in a way that doesn’t adversely impact developer productivity.

    The average developer spends, on average, half a day fixing a single vulnerability, so the impact security issues are having on the rate applications are being developed is significant, added Sass. WhiteSource Cure gives each developer the equivalent of their own personal security expert, noted Sass.

    Developers can either apply the remediation suggested by WhiteSource Cure—that manifests itself as a pull request in a DevOps pipeline—or they can fine-tune it as they see fit, said Sass.

    WhiteSource

    WhiteSource Cure arrived as friction and tensions between developers and cybersecurity teams rise in the wake of a series of high-profile attacks against software supply chains. As a result, organizations are instituting more thorough security reviews of application development projects. The concern is those reviews will dramatically reduce the rate at which applications are being delivered.

    Of course, many organizations are looking to shift responsibility for application security further left toward developers to minimize the number of vulnerabilities that might need to be remediated either just before an application is deployed in an on-premises IT environment or, worse yet, after it is deployed. Trying to achieve that goal within the context of DevSecOps best practices, however, is challenging. Organizations first have to acquire vulnerability scanning tools that developers will actually use, and then provide developers with the training required to identify various classes of vulnerabilities.

    The other big challenge is the time it takes to train developers to recognize vulnerabilities. WhiteSource Cure eliminates the need for developers to become security experts, said Sass. In addition to a commercial offering, WhiteSource is also making available a Community Edition of WhiteSource Cure for open source projects that will forever be available for free to developers working on those projects.

    Sass said that rather than relying on machine learning algorithms and other forms of artificial intelligence (AI) to build WhiteSource Cure, the team that developed the tool found that more traditional approaches to software composition analysis (SCA) provided more reliable results.

    It’s unclear whether the ability to automatically remediate known vulnerabilities in code will render much of the DevSecOps debate moot. However, it’s clear that the simplest path forward toward achieving DevSecOps is, as always, to automate as much of the remediation process as possible. The challenge will be waiting to see how much confidence developers and cybersecurity teams will have in the recommendations generated.

  • JFrog, Vdoo Securing SecOps

    JFrog, Vdoo Securing SecOps

    Earlier this summer, JFrog acquired Vdoo to deliver end-to-end continuous security from development to device—is this what DevSecOps looks like? JFrog CEO Shlomi Ben Hami and Natenel Davidi, CEO of Vdoo, speak with Alan Shimel about what the acquisition means and how this will change the way organizations approach DevSecOps. The video is below, followed by a transcript.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Thanks for joining us here on a special segment of Tech Strong TV. I am really happy to be joined by two gentlemen, one coming to us all the way from Israel, Netanel Davidi from a company called Vdoo, and for those who don’t know, Vdoo is a Hebrew word meaning we understand. What?

    Netanel Davidi: Making sure.

    Shimel: Making sure. And then my second guest needs no introduction to our audience, it’s my friend, Shlomi Ben Hami. Shlomi, of course, is CEO and one of the Co-founders of JFrog, and he’s coming to us, I’m gonna assume, from the swamp in Silicon Valley today?

    Shlomi Ben Haim: You are correct. Great to see you again.

    Shimel: Shlomi, welcome. Good to see you, my friend. It looks like you’ve been in the sun a little—a little tanned. I’m glad to see they’re letting you out a little bit.

    But guys, we’ve got some big news to break today. Nati, you’re a new person—okay, I was gonna say, who wants to break the big news, but up to you, Shlomi.

    Ben Haim: Yes, I think I’ll go first and obviously, Nati—

    Davidi: Okay.

    Ben Haim: – will have far more information to share with all of you. Nati Davidi and the Vdoo team are joining JFrog. We are announcing the acquisition of this wonderful company that will complete our SecOps solution, not just for the DevOps and SecOps pipeline, but all the way to the edge, whatever the edge is, whether it’s a device, a data center, or any other destination.

    And Alan, you’ve heard me so many times saying that DevOps without security is half-baked and crippled, so the solution that we are now building together will take us another leap forward toward our vision of liquid software, and becoming the company behind all the software updates in the world. So ,we are obviously very, very excited to join Nati and the team to the JFrog family.

    Shimel: Congratulations. Thank you, Shlomi. Nati, as we say here in Boca Raton, mazel tov to you and the whole Vdoo team. So, tell our audience—and our audience, Nati, you should know is a very cyber savvy audince. Let’s hear a little bit about the Vdoo story. We know JFrog, but give us a little of the Vdoo story.

    Davidi: Sure. So, it all started almost four years ago when we were an initial team of people coming from endpoint security and a space of software vulnerability expert mitigation. Our previous company, we dealt with it as part of Palo Alto Network, they acquired my previous company, Cyvera, and another part of the group coming from embedded security and the space of reverse engineering and vulnerability research. And we joined together to cope with what we believed three or four years ago to be the biggest problem today in the security space, which is the connected device and embedded systems.

    We call it that way more technically because, clearly, there are very many other good companies out there doing more network security for IoT. We claimed and are still claiming that you need to take care of the source of the problem, which are the manufacturers and the creators of such devices, of such embedded systems, and for that, we established Vdoo.

    So, we did initially, we focused on that, and very quickly, we came up with a platform for product security, focused specifically on embedded systems and IoT, that allows developers and product security stakeholders to analyze automatically any kind of connected device. But when I say analyze, it’s not from the network point of view, but rather analyze the software stack in order to identify any security issue, any of the main buckets like third party issues, issues with your own code, the first party proprietary cloud that you are writing, issues with whatever in between, productization issues, configuration issues, hardening issues, architectural issues, things around cryptography, around how you keep your keys, how you configure things.

    So, we said we want to be the first player that allows everything, truly everything. Look at all of the aspects of security clearly, of course, supply chains, threats within it, and say to the manufacturers of devices, “Take this, and this will be your product security officer in a box, and a product security team in a box.” And it worked well.

    Now, the interesting thing is that, in order to do it, we had only one applicable approach—analyzing binaries. Why? Because in the embedded space, everything is around binaries. You have images of real time operating systems, third party compiled binaries and files and packages that you cannot really see into them what’s going on. You get them in the form of drivers from Qualcomm or AUTOSAR, whatever known library, and the manufacturers need to look into those, and they don’t have the source code. They have to be able to analyze them.

    So, we focused on binaries, and with that, again, we came with the platform and very quickly without even us knowing, our customers started to use us for purposes other than embedded security analysis. They started to analyze web applications, mobile applications, containers. Because when dealing with embedded, which is considered to be the most complicated and advanced or difficult things to analyze automatically, doing the rest is usually more about gaining more data but not developing more technology.

    So, we adapted, and we allowed our customers to analyze the applications that are talking with the devices and the web services that are talking with the devices. And we added more and more capabilities, and by then, we said, “Wait, why focus in on embedded systems if, through the binary analysis approach, we can serve the entire industry, we can provide security for whatever software artifact is out there.”

    And the next thought was, we just need to find the right partner who will deal with binaries. [Laughter] And the answer was, there is one such pioneer, which is known to everyone, which is JFrog.

    So, I asked Shlomi kindly to meet, to consider collaboration, so we can enjoy the many thousands of customers and huge community of JFrog and tell them, “No, use us to analyze your repository on top of Xray. Xray brings great capabilities, we enhance it with more capabilities for zero day analysis, configuration analysis. So, let’s do it together.”

    And that’s how our discussion started and today, we see where it is going and we are very, very excited about it.

    Shimel: What a great story. So, did you get the space two floors from them in order to meet, or were you already there? [Laughter] I’m kidding, I’m kidding.

    Seriously, I mean, my background is—look, I cofounded a company that really pioneered what we used call NAC, right, Network Access Control, and we did it for the U.S. government, for the DoD, right? So, this was not embedded systems, these were every endpoint network device coming on via, you know, 2.1x, we would test configuration vulnerability, et cetera. I know what a tough job that is.

    Once you go into the world of embedded systems, though, it’s like—anything goes, right? As you said, you’ve got Qualcomm drivers, there so much black box stuff. Knowing what’s secure and not is—I can’t even imagine, you know, how you do that. But now, once you’re taking binaries and artifacts, you’re right, there is only one company for you to go to, you know, it’s this man’s company. So, what a great match.

    Shlomi, he mentioned, Nati mentioned Xray. Xray’s a good product. But it’s a very specific product, right? If you’re downloading an artifact from the repository, it’s gonna check that as you’re doing it. This, of course, opens a whole different world of checking downloads and components and so forth. What’s the plan?

    Ben Haim: So, I’ll first start by saying, Alan, that I’m sitting here thinking that this would be probably the only interview in the world that you will have two CEOs that are so excited about binaries. [Laughter]

    Shimel: Yeah. [Laughter]

    Ben Haim: I’m enjoying it.

    Shimel: I think you’re right—you’re right, you win that.

    Ben Haim: So, listen—when we started, we built Artifactory to be the universal repository for all types of artifacts. And very fast, we identified the software package, the binary, as the first level citizen in your DevOps pipeline. There is no other asset that is more important. And why? Not because JFrog thinks so, but because of the fact that this is what you bring from outside, this is what you build inside the organization. This is what you test, this is what you promote, this is what you deploy, and this is the incremental update that you want to see at the end of the day on the edge.

    Now, with this in mind and the liquid software vision to be the company that changed the way software is being updated in the world, it was clear to us that SecOps cannot end on securing your repository. That’s great, that’s a great value. Xray can give you the composition analysis, the dependencies graph, secure your binaries—that’s great.

    But what happens when the Product Manager needs to take a binary? This is where the trust is broken. And we can—you know, every SecOps company, and you met all of them and you know all of them, Alan—every SecOps company will tell you, “We want to kind of build the bridge between developers and security guys.” It will not happen because you don’t use the same currency.

    And when it comes to binaries, both Vdoo and JFrog speak the same language, identify the same pains, and take it very seriously, not just on the development side or then on the testing side or then for the Product Manager side—all the way, all the way to the update, all the way to the deployment to production. So, obviously, we were very excited about what Vdoo had to offer, and it was again, just like everything else in JFrog, a binary question—are we competing or buying?

    And I’m very happy and very pleased to get to this moment now, speaking with you, knowing that the Vdoo guys are joining JFrog. Now, why this is so important from a culture point of view—and Alan, you know me well. You know how culture and the synergy is also about the people. We are bringing approximately 100 people that thinks and program and build their products like hackers. They know how the threat looks like. We are joining them through our hundreds of people that think like developers. What are the chances that this will not bring a better solution, a better blend to the market?

    Shimel: Sure.

    Ben Haim: And with that, I’m taking the next leap forward to fulfill the liquid software vision.

    Shimel: Agreed, agreed. And you know, frankly, it couldn’t come at a better time, right? Because wherever you are in the world today, and look, I’ve been in security 25 years—never has security gotten the attention, real attention, everyone always gave lip service, but real attention now. Whether it’s the supply chain or the ransomware or the whatever the attack du jour is, we are recognizing that cyber, cyber security represents probably one of the most serious threats to our continued transformation, right?

    And we saw this past year, unfortunately, without digital transformation and the move to a connected world software, where would we be, right? We would be in a lot worse shape than we were. And cyber security is the biggest threat to this. We need—we need to stop taking and do more doing, right, when it comes to building more secure software, right? And if people are building software like Shlomi and the team say, liquid software, right, without versions, it’s gotta be secure. And not only, it has to be secure, people have to be confident that it’s secure, right? Because that’s the biggest inhibitor—that’s the inhibitor, the lack of confidence.

    Davidi: And you can see this coming clearly, finally, from the regulators starting to draft bills around it, and you see demand from the end users—not necessarily consumers, but everyone, hospitals, manufacturers, they start to telling, “you want to buy from you, I want your software to be secure.” This is a demand, this is a requirement for RFPs, for RFIs. We see it everywhere. So, this is going to be a boon, because so far, the cyber security space was highly focused on the after the fact security, on the enterprise, care about, take care of it from the very beginning all the way to the network. And this is the only—

    Shimel: No, this builds up material, right, Nati? I’m sure you’re familiar, right? And there’s EEO, the bills of material order. Look, if this thing—you know, why did it take so long? I don’t know, but if this thing catches on that you need to have a bill of material for every software out there, for every app out there, people will, you know—go ahead.

    Ben Haim: I will just add to it, Alan, it also makes sense the way it happened. Look at the digital transformation. We are now facing the second wave of it, and we started to realize, everyone, every organization started to realize that being fast is not good enough. But you have to be fast first ________.

    Shimel: Yeah.

    Ben Haim: And then to build the security solution around it. So, developers delivered. They started to be faster than the security team, and now, security is catching up. But if you look at 99.9 security companies, they are not selling value, they are selling fear. They are telling you what will happen, what will happen if you will not do that. And developers hate that. Developers want to build, they want to have the freedom of choice and to be faster. And the security tools that are not focusing on the right pain have to be sold as fear and not as value. And this is the change that JFrog and Vdoo will bring to the market. Putting ________ aside, we focus on the community pain, as we did with Artifactory, as we did with Xray, as we announced just three weeks ago at swampUP with JFrog distribution. How can you distribute if it’s not secure all the way to the edge?

    Shimel: Okay. We’re running low on time, but let me bring together a little—I need some nuts and bolts, here.

    So, the deal was announced on Tuesday, today’s Thursday. Is it closed yet, was it—without getting into, I know you’re not gonna discuss the particulars, but is the deal closed? If not, when is it supposed to close? When are the Vdoo people, when are these hackers joining the developers, chocolate and peanut butter? When are we gonna see it?

    Ben Haim: Yeah, we hear this question again and again, first from our team, what are the first signs that we would like to see and what are our other plans?

    So, obviously, the definitive agreement is signed, and the closing is supposed to be in the next few weeks. We already have both sides, teams standing ready to merge the products, and the first step will be merging the infrastructure, making sure that this wonderful research that Vdoo is leading with vulnerabilities and database is also merging to Xray so our users can start enjoying that. We are thinking about the product philosophy, the hybrid cloud and on prem—all cloud, all regions, cloud native ready, the unified solution that will be scalable for our users. We have over 6,000 customers that are waiting for something like that.

    So, obviously, we will take the first leap and merge the assets and the low hanging fruit into Xray. And then, during 2022, we will build a unified platform that will include Vdoo’s capabilities into the JFrog platform.

    Shimel: Excellent. Excellent. Nati, just a question for you. I mean, obviously, all the people at Vdoo will stay on at JFrog. For people who may be very familiar with JFrog but have not heard of Vdoo, what’s the Vdoo website?

    Davidi: It’s Vdoo, V-D-O-O dot com.

    Shimel: Excellent. Alright. You can go find out more about it there. As I said in the beginning, Nati—congratulations, mazel tov on…you know, I learned from a mentor once, it’s kinda like a boat. The best two days are the day you start the company and the day you sell your company, so congratulations on that, it’s a beautiful thing.

    Congratulations to you, my friend, Shlomi, right? This is a piece of the puzzle that was missing and it’s important, and it’s gonna be more important every day going forward, so—good stuff.

    Ben Haim: It’s important, it’s a very, very exciting market for us. It’s increasing our addressable markets, and more than everything, we’re bringing over almost 100 people that have the same DNA and the green blood just like JFrog.

    Shimel: Look, getting 100 security experts at a shot—that alone might be worth it, because they’re hard to come by, my friend. Alright, Nati, congratulations. Shlomi Ben Haim, CEO—thank you, as always, my friend.

    This is Alan Shimel, we’re on Tech Strong TV. We’re gonna take a break. We’ll be back in a moment.

    [End of Audio]

  • Redefining Continuous Security for DevSecOps

    Redefining Continuous Security for DevSecOps

    In the mobile app development world, security often takes a backseat to developing features and delivering the app. In fact, the 2021 Verizon Mobile Security Index found that 45% of organizations sacrificed mobile security in order to “get the job done.”

    It really shouldn’t come as a surprise. Certainly, it seems counterintuitive that mobile app development organizations would spend so much time and money to create an exceptional Android or iOS app and then fail to protect it against rooting, jailbreaking, reversing, hacking and other kinds of malicious manipulation. But the average mobile developer releases 12 apps each year; a frenetic pace that requires development to take place in parallel, without ceasing. Schedules and budgets are tight, and competition is fierce. Coding security into an app is both expensive and time-consuming, increasing the risk of a delayed release or budget overages.

    In many organizations, if security is implemented into a mobile app at all, the process takes place during penetration testing. That’s too late, and it’s extremely inefficient. Waiting to implement security after development and delivery are essentially finished will anger developers because now, they have to dive back into their code to make complex changes to work they thought was finished. The code is no longer fresh, so it’s going to take more time than it would have if security implementation had taken place during the development process itself.

    But integrating security into the development process is no simple task either. Imagine two friends are spinning a couple of jump ropes. Jumping in the middle without stepping or tripping on either of the ropes while they are moving is difficult. Each time a security feature is introduced into a mobile app’s software development life cycle (SDLC), the person building the security could step on the rope. Building security features takes time, and they are hard to build and maintain.

    Our Oversimplified Model of DevSecOps

    To solve this problem, DevSecOps was introduced to resolve this conflict and overcome the challenge of integrating security into the mobile SDLC. The idea is that organizations can develop features and incorporate security simultaneously. So far, much of the emphasis in DevSecOps has been focused on the processes development, security and operations that teams use to build, protect and release apps. People have done heroic work creating cultures of security and secure coding practices, which has moved the industry forward toward more secure mobile apps for everyone.

    Let’s take the jump rope analogy a bit further. One friend holding the ropes is the development and engineering team, while the other is the ops/release team. The ropes each represent an iOS and an Android app. In most organizations, the ropes are moving at blazing speeds, as apps are churned out one after the other. Meanwhile, on the sidelines, there’s the security team, whose job is to make sure the ropes meet security objectives, jumping in where needed, all without stopping the ropes from spinning.

    The trouble is that each group has different skills and objectives. Developers aren’t typically security engineers, and security teams don’t typically have developers. Neither group has the resources or skills to meet the needs of the other, and whenever they try, one of them trips on the rope.

    Mobile DevSecOps, Meet Continuous Security

    The only way to keep the current breakneck pace of app releases going while simultaneously providing security is to introduce as much automation as possible. AI systems can fuse security to an app more cost-effectively and consistently, complete with validation that the features required have been implemented. It’s different from code scanning, which occurs after the app is built and leaves remediation to the dev team. I’m proposing that the implementation of security itself be automated.

    The growing threats to mobile apps are too significant for development teams to ignore, but so are the market pressures that force such short delivery timescales. The only way out of this dilemma is extensive automation. Otherwise, the dev and sec teams will keep continuously tripping on each other’s ropes.

  • CloudTruth Acquires Tuono to Advance Configuration Management

    CloudTruth Acquires Tuono to Advance Configuration Management

    CloudTruth, a provider of a unified configuration management platform, today revealed it has acquired Tuono, a provider of a cloud secrets management platform, as part of an effort to make it simpler to secure infrastructure provisioned using code. Terms of the deal were not disclosed.

    Greg Arnette, CloudTruth CEO, said misconfigurations are rife across cloud computing environments. IT organizations now need a self-documenting approach to managing configurations as the number of cloud services that organizations can employ continue to multiply. The CloudTruth platform will automatically keep track of all configuration changes made to an IT environment, Arnette said.

    The rise of Kubernetes and microservices is making things even more challenging, introducing a range of additional opportunities to misconfigure cloud platforms and applications.

    Fresh from raising $5.25 million in seed funding, Arnette said one of the least-appreciated aspects of the configuration challenge is how dependent organizations are on tribal knowledge that gets shared unevenly across DevOps teams. The lack of a centralized repository for managing configurations makes it challenging to onboard new members to those DevOps teams, he added, resulting in more opportunities for mistakes to be made.

    Tuono adds a cloud-native secrets management platform that can be deployed across multiple cloud services. The goal is to provide a configuration management platform that functions as a metadata wrapper compatible with configuration tools such as Terraform or CloudFormation from Amazon Web Services (AWS). That approach reduces the cognitive load on DevOps teams that would otherwise have to remember how and why each service is configured the way it is, said Arnette.

    Arnette added that an additional goal is to enable DevOps teams to put guardrails in place that reduce the opportunities for misconfiguration errors to be made while continuing to enable developers to build and deploy applications quickly. Each organization will need to decide where to strike a balance between those competing agendas, noted Arnette.

    The challenge organizations are wrestling with today is just how vulnerable software supply chains are—as a series of cybersecurity attacks have made all too apparent. Organizations are adopting DevSecOps best practices to better secure those supply chains. However, the rate at which DevOps teams can come up to speed on security isn’t fast enough to secure applications that are about to be deployed. At the same time, there are potentially hundreds of applications deployed in cloud platforms with varying degrees of misconfigurations. Cybersecurity teams are now being asked to review how well those applications are configured as part of an effort to address the security of the entire software supply chain.

    It’s not clear if a backlash against DevOps, in general, is in the making as cybersecurity teams review application development and deployment practices. There undoubtedly will have to be adjustments made to those processes, even as most organizations realize just how dependent they are on software. The issue is that deploying more insecure applications faster is, at the end of the day, counterproductive.

  • Aqua Security Acquires tfsec to Advance DevSecOps

    Aqua Security Acquires tfsec to Advance DevSecOps

    Aqua Security today announced it has acquired tfsec, an open source project that provides a static analysis scanner for infrastructure-as-code (IaC) that is designed to be integrated within a DevOps workflow.

    Amer Jerbi, Aqua Security CTO, said tfsec extends the security platform the company already provides in a way that advances adoption of DevSecOps best practices. In addition, to prevent developers from misconfiguring cloud infrastructure using tools such as Terraform, the scanner surfaces examples of code that provide developers with insights into how to properly configure infrastructure.

    Jerbi noted that tfsec is already integrated with Aqua Trivy, an open source tool that scans container images for vulnerabilities. Integrations with the rest of the Aqua Security portfolio will follow, added Jerbi.

    Tfsec co-founders Liam Galvin and Owen Rumney will join Aqua Security as cloud engineers. The challenge Aqua Security is trying to address is the need to enable organizations to proactively prevent cybersecurity issues from arising in production environments rather than only identifying vulnerabilities that need to be fixed, said Jerbi.

    Aqua Security tfsec

    The decision to acquire tfsec comes in the wake of a series of high-profile breaches when many organizations are scrambling to make sure software supply chains are secure. Cloud platforms are rife with misconfigurations mainly because developers often lack the expertise needed to ensure infrastructure is secure after they have provisioned it. Organizations are embracing DevSecOps best practices in the hopes of educating developers to assume more responsibility for application security. However, developers are not going to acquire that expertise overnight. The tfsec scanner provides a way to enforce security policies today while at the same time affording the time to teach developers how to avoid misconfigurations.

    It’s unclear how many cybersecurity events arise because of cloud misconfiguration issues. The cloud service providers have adopted a shared responsibility model that makes the organization employing the cloud responsible for both the applications deployed on those clouds and for how that infrastructure is provisioned. Many developers that provision cloud infrastructure themselves within the context of a DevOps workflow often assume the cloud service provider is doing more than it is to prevent misconfigurations. Cybercriminals, meanwhile, have become very adept at scanning for those misconfigurations.

    There are, of course, a lot of layers and nuances when it comes to DevSecOps. Arguably, Jerbi said, the most critical thing for most organizations is to simply get started. Tools that can be quickly and easily integrated within an existing DevOps workflow with minimal disruption are critical, Jerbi added.

    In the meantime, DevOps teams should expect cybersecurity teams to become more involved in their workflows, especially as government mandates aimed at securing software supply chains become stricter. Eventually, as organizations gain confidence in the ability of their DevOps teams to secure their application environments, those cybersecurity teams will refocus their efforts on hunting for threats. In the meantime, DevOps teams would be well-advised to make those cybersecurity professionals feel as welcome as possible, given the application security mandate most of them have been given.

  • 8 Security Considerations for CI/CD

    8 Security Considerations for CI/CD

    In the software development enterprise, CI/CD refers to the combined practices of continuous integration and either continuous delivery or continuous deployment. CI/CD enables organizations to bridge the gap between development, operation activities and teams by the use of automation when building, testing and deploying applications. 

    How do you maintain quality and security with frequent deployments? While CI/CD can improve the efficiency of an organization, there are many security considerations to take into account.

    To gain insights on the top security considerations for CI/CD, I asked the speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors for their thoughts. Here’s what they had to say in part one of this two-part series:

    Speaker, Grant Fritchey, Product Advocate, Redgate Software

    “There are a lot of security considerations when it comes to CI/CD. As a person focused on data and data management, I’m going to say that the top security consideration is ensuring that you have compliant data for your non-production environments. Just the sheer number of people who will have access to the information means that you have a huge number of possible vectors for a breach if you’re exposing protected information.”

    Speaker, Anders Wallgren, VP of Technology Strategy, CloudBees

    “Secure your software delivery pipelines themselves, not just the software that you deliver with those pipelines. Everyone should have only the level of access they require in order to perform their role.

    Maintain a Software Bill of Materials (SBOM) so you know what you have in production. When a new vulnerability is disclosed, you will have a much easier time deciding whether and how to mitigate it if you don’t have to chase down what you have in production. Your orchestration software should do the lion’s share of the work here.”

    Tracy Ragan, CEO and co-founder, DeployHub

    “CI/CD tools are driven mainly by one-off scripts. There is absolutely nothing secure about one-off scripts. From build through deploy, we need to start thinking of implementing automation and policy-driven tools and dump the one-off scripts.”

    Tiffany Jachja, Technical Evangelist, Harness

    “Supply chain management is a major security consideration for CI/CD. If an entity gains access to a CI/CD resource or component that they shouldn’t, this can lead to vulnerabilities, downtime or even malicious code. For example, in the SolarWinds hack of 2020, attackers legitimized their software malware by injecting it into the SolarWinds build process. This build pipeline produced trusted software artifacts and obtained digital certifications before being released to over 18,000 customers worldwide. After the hack, SolarWinds took action, further restricting access to its build environment and reviewing its build process, but not before it was too late. It’s not only about automating developer and operations workflows but also how we treat and handle CI/CD pipelines.”

    Jamal Walsh, Technical Product Owner, The Very Group

    “You must make sure you implement security tooling within your pipeline; it’s not enough to just use CI/CD to build and deploy applications. Steps in your pipeline should include security testing tools like SAST, DAST, dependency checks, etc.”

    Martin Chan, System Analyst, Global Executive Consultants Ltd. 

    “The most important thing is to define the access control list and rules to control the access in the CI/CD pipeline so that the audit log can easily trace issues. Also, the system should require authentication and define password policies for all users.”

    Bryan Finster, Software Engineer, DoD Platform One

    “Security must be automated as part of the pipeline. Just like any other quality gate, the pipeline must be the single source of truth for security. Any manual process after code is committed increases the effort to deliver. Increased effort increases the size of each change. Larger changes are harder to check for quality and fail more spectacularly. Manual security is just security theater and is easily bypassed or forgotten. That effort is better spent improving the ability of the pipeline to use security as-a-service.”

    Dheeraj Nayal, Global Community Ambassador, DevOps Institute

    “Follow the three security best practices for CI/CD. We usually divide security practices into three parts that you can address with different kinds of solutions. These are:

    1. Secure pipeline configuration
    2. Code and Git history analysis
    3. Security policy enforcement

    All three aspects are equally important.”

    If you’d like to learn more about the latest in CI/CD and similar topics, check out the upcoming SKILup Day schedule. Or, learn more about the benefits of becoming a DevOps Institute Member. 

     

  • Fugue Aims to Simplify Securing Infrastructure-as-Code

    Fugue Aims to Simplify Securing Infrastructure-as-Code

    Fugue today unveiled a 1.0 release for Regula, an open source policy engine for infrastructure-as-code (IaC) security that comes with prebuilt libraries for implementing hundreds of policies that validate configurations on Amazon Web Services (AWS), Microsoft Azure and Google Cloud services.

    Regula is based on the Open Policy Agent (OPA) software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is compatible with both Terraform and AWS CloudFormation tools for configuring cloud infrastructure.

    Developers can also build custom rules on top of OPA using libraries that Fugue created for the Rego programing language that is part of the OPA specification. Regula supports output formats such as JUnit, Test Anything Protocol (TAP) and JSON to make it easier to integrate Regula with other tools and frameworks that make up a DevOps workflow. Input formats supported include Terraform HCL, Terraform plan JSON, AWS CloudFormation and Serverless Application Model templates.

    Regula also provides out-of-the-box support for the CIS Foundations Benchmarks in addition to other policies defined by Fugue, such as dangerously permissive identity access management (IAM) policies, Lambda function policies allowing global access, volumes with encryption disabled and untagged cloud resources.

    It is deployed as a pre-packaged binary that includes a command line interface (CLI) through which Regula can be incorporated within a DevOps workflow and can be installed using tools such as Homebrew or deployed as a Docker image.

    Fugue CEO Josh Stella said Regula provides DevOps teams with an extensive library of rules that check for common security and compliance violations as well as advanced multi-resource misconfigurations. That latter issue is especially challenging because developers typically don’t have much visibility into dependencies that can inadvertently provide cybercriminals with access to, for example, an S3 cloud storage bucket that otherwise appears to be configured properly. Regula will also identify any required resources that might be missing, as well, added Stella.

    Stella said Regula 1.0 provides a simpler approach to securing cloud infrastructure. Cloud infrastructure is frequently misconfigured simply because a developer made a mistake. Unfortunately, cybercriminals have become especially adept at scanning cloud platforms for these misconfigurations, noted Stella.

    It’s not clear to what degree a backlash might be building against IaC in the wake of recent high-profile breaches of software supply chains. Organizations have embraced IaC tools to make developers more productive. However, each security incident involving a misconfiguration of cloud infrastructure resources makes it all too apparent that developers lack the expertise required to securely provision IT environments. Rather than creating a series of cybersecurity reviews that would reduce developer productivity, Stella said Fugue is making a case for a compliance-as-code approach that developers can readily understand and implement.

    One way or another, cloud infrastructure has to become more secure. Business leaders are growing weary of security incidents that, from their perspective, are caused by careless mistakes. Their first instinct is to empower cybersecurity teams to resolve those issues once and for all. The only issue that needs to be resolved now is just how cumbersome those security reviews need to be if developers are provided with the tooling required to secure cloud platforms themselves.