devopsy.kinsta.cloud

Tag: devsecops

  • Raytheon Leans on Red Hat to Advance DevSecOps

    Raytheon Leans on Red Hat to Advance DevSecOps

    Raytheon Company is partnering with Red Hat to drive the adoption of DevSecOps workflows and processes it developed around the OpenShift application development and deployment platform.

    Jon Check, senior director for cyber protection solutions for Raytheon Intelligence, Information and Services, said Raytheon has developed a set of DevSecOps practices for organizations building applications deployed in highly secure environments, involving government contracts.

    Raytheon and these customers have been challenged by a chronic shortage of IT professionals with the appropriate level of clearance to work on these classified projects. To overcome that issue, Check said Raytheon developed what it describes as a “code low, deploy high” approach to DevSecOps. Developers who lack security clearances can still build applications; however, those applications can only be deployed by IT professionals having the appropriate security clearance.

    In addition, Check said Raytheon has developed integrations between its DevSecOps framework and various IT tools based on the ITIL framework, which so many IT operations teams depend on to foster collaboration across the application development and deployment process. For example, he said, whenever code gets checked into a repository, an alert can be sent to an IT service management application from ServiceNow.

    That approach enables organizations to build applications quickly without compromising the integrity of the deployment platform, Check noted. Now Raytheon is working with Red Hat to drive adoption of its approach to DevOps to organizations beyond the core vertical industry and government sectors it serves.

    Check said Raytheon chose to work with Red Hat because organizations are now building applications employing microservices based on containers that they want to be able to deploy on any cloud computing environment. Those environments include edge computing platforms to process data in near real-time closer to the point where data is collected.

    In addition, Check noted Red Hat OpenShift is built on Red Hat Enterprise Linux (RHEL), the first operating system to achieve Common Criteria certification with Linux Container Framework Support. Red Hat also assumes responsibility for curating the underlying open source operating system and application deployment platform.

    In general, Check noted that while there’s a lot of interest in deploying code faster these days, the deployment of insecure applications is counterproductive. Organizations too often find themselves rolling back application deployments to deal with one cybersecurity issue or another. By separating application development and deployment, Raytheon is making the case for a DevSecOps approach that enables more secure application code to be deployed faster, he said.

    Each organization will have to determine what rate of application deployment is fast enough for them. The more sensitive the application is, the more an organization is likely to want to be more deliberate when it comes time to deploy and update an application. However, the need to be deliberate doesn’t necessarily mean organizations should continue to rely on legacy approaches to application development and deployment based on waterfall methodologies.

    — Mike Vizard

  • DevOps: Get the Basics Right to Avoid Costly Mistakes

    DevOps: Get the Basics Right to Avoid Costly Mistakes

    It is a truth of both agile and DevOps that speed is of the essence. This is a relative statement—some apps/portfolios/orgs envision speed completely differently than others—but if you are releasing more frequently than you were in the past, thanks to DevOps, that’s kind of the point.

    Yet, we see a whole selection of things that fall by the wayside or are underserved. Security and testing are the easy/obvious ones. Considering the frequency with which we see “Unsecured Amazon storage bucket” (one announcement of this type spurred this blog), should we not see this folded into standard procedure or tools? Well, it is folded into standard tools for checking your cloud environment—I’ve used a couple of them and seen this warning come up. So shouldn’t organizations be using these tools more?

    One thing about speed: It tends to cut corners. And cut corners lead to lapses. You can be a blameless environment that doesn’t punish people for mistakes, but for an organization, a mistake such as exposing hundreds of thousands of users will be punished from the outside, from regulatory agencies and the market in general. They’re not mistakes we should be making, and yet it still happens.

    Another one is rollback versus roll forward. Most DevOps shops focus on the ability to fix an issue and plow forward. This works really well, 90+% of the time, and fails spectacularly sometimes. While it is an added step with some slowing of process, being able to roll back changes is important. And more than, “Well, theoretically, Git will allow us to go back to the last marked release …” because there is far more to an application architecture than just the source stored in a repository.

    In short, no matter how fast things are going, have a plan for when things go wrong. Because they inevitably will. And take the little bit of extra time for preventatives such as warning someone other than the creator about buckets with no security.

    “But there isn’t time …” is the common refrain to blogs such as this one. I get it. The increase in delivery only creates an increased appetite for delivery. But is there time to respond to disaster, should the worst happen? And I’d argue that it must be IT that plans for disasters. When someone gets fired because there was a security breach or a total systems failure, it is rarely an app owner. That puts the responsibility to make certain one doesn’t happen squarely on IT.

    We’re delivering faster, offering increased functionality to users, moving forward on every front. You all are out there rocking it daily. Don’t risk all of that being ignored because you failed to take care of basic issues. Check out the tools to help out; feature flags and cloud security scanners both spring to mind with regard to my examples above. The tools are out there, you just have to work them into your process.

    — Don Macvittie

  • DevSecOps Adoption and the Web Security Myth

    DevSecOps Adoption and the Web Security Myth

    As DevOps practices have become widespread in the tech community, many people have begun proclaiming the virtues of DevSecOps. As the name implies, DevSecOps is the addition of security into DevOps. Just as DevOps promises better-quality production in less time, DevSecOps promises better security with less time required to achieve and maintain it.

    DevSecOps has many benefits. However, many executives are under the impression they can’t embrace DevSecOps across their entire organization.

    This idea is false. Most organizations that have already adopted DevOps can, and should, take the next logical step and adopt DevSecOps as well.

    ‘It Sounds Great, But We Can’t Use It Here’

    Adopting DevOps requires far-reaching changes throughout an organization. Going to DevSecOps can be similarly disruptive. However, internal disruption is not usually the (perceived) problem with DevSecOps.

    Instead, the problem is usually the network border. Many executives believe that their current web security solutions are incompatible with DevSecOps.

    In many cases, this is actually true. Older approaches to web security are indeed hindrances to DevSecOps practices.

    Therefore, the problem isn’t actually with DevSecOps. The problem comes from the security solutions currently in use.

    Legacy Security Solutions and DevSecOps

    Many organizations are still using appliances (whether physical or virtual) as their primary protection against external threats. A decade ago, appliances were good enough. Today, they’re a competitive disadvantage.

    There are several ways in which appliances are incompatible with DevSecOps:

    • Programmatic control of an appliance is often difficult if it’s even supported at all.
    • Configuring an appliance can be challenging. It often requires a high level of security expertise.
    • Rolling out settings and configuration changes across a bank of appliances can be time-consuming and potentially error-prone.
    • The cost and specialized nature of most appliances make them inconsistent with the DevOps mantra of “cattle, not pets.”
    • Physical appliances do not scale.
    • External-facing applications will be limited in their scaling as well.
    • Appliances are not designed for ephemeral workflows.
    • Appliances are not designed to support infrastructure as code (IaC).

    Security appliances represent a decades-old approach to security, so it’s not surprising they don’t support modern practices. What is surprising is that even many allegedly “cloud-native” solutions aren’t built for DevSecOps, either.

    For example, some require multiple instances to be launched into your environments. Some require additional layers of management just to maintain consistent configuration among them. Many do not provide good support for evolving architectures and expanding deployments. In general, these security products tend to require significant intervention and management, while lacking automated control capability. This all severely limits the use of DevSecOps.

    These appliances and incorrectly labeled “cloud-native” solutions are why many executives believe DevSecOps isn’t an option for their organizations. To be clear, these executives are correct—for as long as they continue to use previous-generation approaches to web security.

    Not Just a DevSecOps Issue

    Older approaches to web security have other problems that go beyond a hindrance to DevSecOps usage.

    For example, appliances are marketed as complete web security solutions, but they cannot actually fulfill this role. Among other things, an appliance cannot defend against a volumetric DDoS. The attack can overwhelm the upstream ISP before the appliance even has a chance to scrub the traffic. This can result in the ISP blackholing all incoming traffic, which makes the targeted site and web applications unavailable to users and customers—which is the exact situation the appliance was supposed to prevent.

    Solving the Problem

    Organizations which are still using older security technologies should re-evaluate this decision. Modern solutions such as cloud web security platforms can provide better protection, along with numerous other benefits. These include full management by the provider, real-time reporting and traffic control, adaptive threat identification based on machine learning and much more.

    When organizations continue to use legacy security solutions, they not only prevent themselves from enjoying the benefits of DevSecOps, they are also missing out on many other benefits as well.

    — Maksim Blishchik

  • NetFoundry Network Overlay Advances DevSecOps

    NetFoundry Network Overlay Advances DevSecOps

    NetFoundry, at the recent KubeCon + CloudNativeCon 2019 conference, announced the general availability of a developer platform designed to make it easier for organizations to bake a zero trust networking framework within their applications.

    Company CEO Galeal Zino said NetFoundry has created a network fabric overlay to manage and secure communications between endpoints and applications. Developers now can embed a programmable zero trust networking framework within their applications using a NetFoundry Developer Platform, which consists of software development kits, application programming interfaces (APIs) and connectors, said Zino. DevOps teams can either consume the entire NetFoundry Developer Platform or only the open source components that have been included.

    At the same time, NetFoundry announced it has joined the Cloud Native Computing Foundation (CNCF) to advance the adoption of open source networking services for containerized applications.

    NetFoundry

    Rather than having to become intimately familiar with networking protocols, Zino says NetFoundry provides a layer of abstraction using software to eliminate the need to rely on virtual private networks (VPNs) or network address translation (NAT) tools.

    As the number of endpoints and applications they need to connect to have significantly increased, DevOps teams are finding they need to master each type of dedicated network established for endpoints ranging from mobile computing devices to internet of things (IoT). That endeavor can be cumbersome at best. NetFoundry is making the case for a programmable network overlay that allows endpoints to access applications over public internet connections securely.

    As programmable overlays become more widely available, the rate at which network operations will be incorporated into best DevOps processes is likely to increase. Network managers will continue to set up the physical underlay that enables networking; however, how applications employ that underlay increasingly will be determined by invoking a programmable overlay. A programmable network overlay also provides the benefit of further separation of duties between DevOps teams and networking professionals in a way that doesn’t require networking teams to become deeply involved in every application development project.

    That approach should reduce significantly the amount of time now required to deploy or update a distributed computing application. DevOps teams today may be able to push code into production faster than ever. However, configuring the networking services those applications require remains a set of manual tasks that have become a significant bottleneck to making IT teams more agile.

    It remains to be seen to what degree programmable network overlays will provide something of a demilitarized zone (DMZ) between DevOps teams and networking professionals. Today most networking services are provided via either directly on top of networking infrastructure or using network overlays controlled by networking teams. But it still takes days to weeks for networking professionals to respond to requests for services from DevOps teams. It’s clear the way networking services are provisioned across the enterprise needs to change substantially.

    — Mike Vizard

  • What Are AWS Application Patterns?

    What Are AWS Application Patterns?

    The cloud-native approach is not just about compute power and cloud services. A “set it and forget it” attitude won’t work with cloud native; there are far too many moving pieces and there is just way too much complexity. Instead, this approach requires constant testing, optimization and improvement. This is epitomized in the two key phrases of the DevOps methodology: continuous integration and continuous delivery.

    To make this a reality, however, it takes a strategic approach to defining application patterns that will govern the way in which cloud-native applications are built and shipped, rather than a one-off effort. Since AWS is the leading cloud provider, we should discuss which application patterns are relevant to the AWS platform. There are many aspects to consider when it comes to AWS application patterns, and we will cover them here.

    Operational Excellence

    The best starting point for application patterns is a commitment to operational excellence. Typically, the term “Ops” is used to identify the IT team, but in this case, operational excellence rests on the shoulders of Dev, QA and Ops teams. In cross-functional DevOps teams, every member should strive for operational excellence at every step–even in the smallest of tasks.

    In their white paper on operational excellence, AWS encourages its users to manage operations as code. This helps avoid human error, enables automation of complex processes and allows for quick and easy rollback when errors occur. Failure, according to AWS, is an opportunity for learning. They even advise performing “pre-mortems” that try to anticipate potential points of failure before a deployment.

    AWS Trusted Advisor is a useful tool that enables this type of accountability and shared responsibility within a team. It checks and reviews your new and existing AWS workloads looking for opportunities to save costs, improve performance, tighten security or follow best practices for scaling operations.

    Security

    Security is a pattern that is non-negotiable. The term “DevOps” has inspired another variation called DevSecOps that signifies this fact. Security operations take center stage when talking about DevOps.

    The interesting thing about DevSecOps is it actually results in more freedom, flexibility and trust across teams when done right. This is unlike traditional approaches to security which created silos, stifled creativity and slowed down innovation. Security is now a key piece of the puzzle, not an afterthought. AWS has many machine learning-based security solutions such as Macie which automatically identifies and secures personally identifiable information (PII).

    Along with this, configuring role-based access controls using AWS IAM is essential to have greater control over who or which applications access data and for how long. Access Control Lists govern access to data stored in AWS S3 buckets.

    The news is full of instances of data breaches due to weak security policies and access controls. Capital One is a recent example of a data breach that affected 100 million of its users. While security in the cloud is more complex than before, AWS has the necessary tools and systems in place. It’s up to organizations to implement a security strategy that prevents misuse of their data.

    Reliability

    Today, there is a low tolerance for downtime because of the potential loss of revenue. With the stakes so high, reliability is a pattern any application custodian would have high on their list of priorities. AWS has multiple reporting and health monitoring tools to keep you constantly on the pulse of your applications.

    Architectural patterns like microservices enable better resilience by decomposing monolithic applications into more manageable chunks called services. This “divide and conquer” approach leads to higher availability, which is critical for SaaS applications.

    Patterns like chaos engineering seek to intentionally kill random instances and services and force the DevOps team to figure out workarounds and backups for every scenario.

    Application Performance

    With the explosion of data, applications are always dealing with lots of data to transfer, store and process. An application’s performance depends on three factors: the backend data storage layer, the middleware components and the frontend.

    The backend data layer is the most critical component when it comes to performance. Choosing the right storage formats, database types, storage devices and organization patterns all contribute to the speed of data access. AWS has an amazing array of storage services, including S3, RedShift, Aurora and Glacier. AWS gives its users every type of storage solution, all of which should be considered to improve data management.

    AWS is devising new ways to query large datasets without bearing the load on your existing systems. RedShift Spectrum is one example of this. It is a great way to “minimize the need to scale Redshift with a new node, which can be expensive.” If you’d still rather not have to manage any RedShift clusters on your own AWS Athena is a great serverless alternative

    That gives you all the power you need to query large datasets in S3 without having to maintain any clusters of your own.

    This pay-per-use model is making its ways across the entire AWS stack with services such as ECS and Fargate offering completely serverless experiences when operating containers at scale. What started out with AWS Lambda is catching on fast, and many AWS services like the ones mentioned above enable serverless experiences with a focus on application performance.

    Cost Optimization

    When moving to the cloud, pricing is completely different. Rather than paying for perpetual licenses, you now pay a small fee for every small resource that you use. Though small on its own, you’ll soon realize that cloud costs can shoot up easily if you’re not paying close attention to your spending.

    Cost optimization is necessary as you scale operations in the cloud. Cost optimization includes looking for more efficient services, whether that’s within the same vendor platform or a different platform. At a minimum it may require a lift-and-shift approach to transition from expensive old infrastructure to inexpensive new alternatives. For example, shifting workloads from VMs to containers to serverless within the same platform can show great cost savings, since containers and serverless are generally more cost-effective than VMs.

    It pays to leverage the expertise of experts in this area. They should ideally be people who have spent years using AWS, understand Well-Architected best practices and have found ways to cut costs and derive more value from the same budget.

    Application Patterns Enable Extensibility

    Microservice applications adopt a pluggable architecture. This enables them to be easily integrated with external applications. Typically, API-based communication patterns are most common. AWS API Gateway is a service that manages API design for AWS applications. In some cases, an SDK is the better choice–for example, when you need more control over the developer experience and integrations. It’s important to know when to choose either option.

    Application Patterns Enable Portability

    Portability is the ability to move workloads across instances without interrupting their functioning. As instances change, the workloads which they support shouldn’t be affected. This is only possible if there is a clear separation layer between the workloads and the infrastructure that runs them.

    Application Patterns Enable Shift-Left

    The DevOps methodology is known to encourage a shift-left approach to software delivery. This means that not only Dev, but also QA and Ops contribute to the design and development stage of an application. This fosters deeper collaboration across teams and breaks down silos.

    A shift-right approach holds true as well. Shift-right means developers are responsible for the code they write. They are equal owners with operations teams for the resilience of the apps they build and also the bugs they introduce into the system. This practice of putting ownership and responsibility where it belongs is very healthy for a DevOps team.

    AWS facilitates pipeline management using tools such as CodePipeline, CodeCommit and CodeDeploy. They each perform similar but complementary roles and help build a CI/CD pipeline. They make it easy to get started with CI/CD within the AWS platform.

    For organizations further down the line in their cloud journey, AWS’ pipeline management tools may seem too simplistic for something like GitOps. Instead, they’d want to look outside AWS for tools such as Jenkins X or Weave Flux which are designed with GitOps automation in mind. Whether it’s the simple or advanced route, a pipeline brings great benefits over a manual development process.

    Conclusion

    Though tools enable the implementation of helpful application patterns, on their own, they are ineffective. Application patterns need a deliberate strategy and an approach for a start. Only after a strategy is in place, can you move to deciding which tools to use. With a strong strategy in place, any of the tools mentioned here can be swapped out for other better tools and the results will be the same. It’s important to not be distracted by the next shiny tool but keep a keen focus on the strategy for implementing AWS application patterns.

    As we’ve seen here, application patterns are diverse, but they all build upon each other. Without even one of these pillars, organizations would not be able to realize the goal of cloud-native applications. On the other hand, if they give careful thought to each of these application patterns, organizations would deliver cutting-edge applications that can only get better with the passing of time.

    This sponsored article was written on behalf of Eplexity.

    — Twain Taylor

  • Survey Surfaces Uneven Approaches to DevSecOps

    Survey Surfaces Uneven Approaches to DevSecOps

    A ZeroNorth survey shows implementing DevSecOps is rife with questions for many organizations, with no clear answers

    There’s general agreement that digital business transformation initiatives are driving an overall acceleration in the rate at which applications are developed. At the same time, however, given the critical nature of those applications, cybersecurity has never been more of an imperative for DevOps teams. The challenge they are encountering is not so much a lack of tools to address that requirement, but rather a lack of clarity in terms of what tool to use when.

    A survey of 57 cybersecurity professionals conducted by ZeroNorth, a provider of a platform for orchestrating vulnerability scanning tools, highlights the extent of the DevSecOps challenge. The survey finds 63% of respondents said their organization currently employs six or more scanning tools. The most widely employed are network scanning (53%) and vulnerability scanning (51%). However, a quarter (25%) don’t know if their organization is using interactive application security testing (IAST), while 19% don’t know if they are using software composition analysis (SCA) tools.

    As far as DevSecOps is concerned, there’s little to no clarity in terms of where to primarily focus scanning efforts. Build/CI environments (68%) receive the most focus, but 46% are focused on scanning within integrated development environments (IDEs). Container/artifact management (67%), source code repositories (58%) and deployment (56%) all fall somewhere in between, the survey finds.

    There’s also no clear consensus on the merits of open source versus commercial testing tools Open source software (OSS) tools were identified as a priority for less than half of respondents (47%). However, 27% of respondents said they expect to begin using open source tools in 2020. Of the respondents currently employing OSS tools, 14% said believe these tools are more effective than commercial test and scan tools. Well over a third (39%) said they believe they are more effective when combined or customized. Just under a third (32%) said OSS tools are equally as effective as commercial options, while only 9% said they are less effective.

    The survey also shows disparity when it comes to the various areas that make up a digital business transformation, with the most mature being cloud migration (80%), followed by DevOps (67%), continuous integration/continuous delivery (CI/CD) (62%) and microservices (62%). Overall, 79% of respondents said they have a digital business initiative underway.

    ZeroNorth CTO John Steven said it’s clear that in many cases, the need for faster iterations of application development is outpacing the operational capabilities of IT organizations, especially when it comes to DevSecOps. Given the chronic shortage of cybersecurity professionals, there may be an average of only one cybersecurity professional for every 100 developers. Having cybersecurity professionals participate in every scrum session isn’t feasible, so there needs to be a way for cybersecurity professionals to provide guidance to developers specifically when it comes to what scanning tool should be applied and when, said Steven.

    The survey finds network (53%) and vulnerability (51%) scanning are the most broadly employed. However, that also suggests that many IT teams involved in digital business transformation initiatives are not making use of scanning at all.

    The good news is that survey respondents said identifying bugs, flaws and vulnerabilities throughout the software development life cycle (SDLC) is either “extremely” (58%) or “very” (42%) important to all participants involved. A total of 47% said it was either “extremely important” or “very important (35%) to improve visibility around operations by integrating security earlier into the software development life cycle (SDLC). However, while the DevSecOps spirit may be willing, the ability to implement best DevSecOps practices is still clearly weak.

    — Mike Vizard

  • Five Tips to Approach DevSecOps Training

    Five Tips to Approach DevSecOps Training

    Developers are on the front lines when it comes to protecting their organizations from cyberattacks. As we’ve seen with the hacks of Monster.com or the Fortnite vulnerability, 2019 has been a trying year for organizations who have failed to protect their applications and websites.

    With an increase of cyberthreats today, it is vital that organizations and developers incorporate standard security protocols within DevOps, a practice known as DevSecOps. Whether exploring these practices around security training, skills, metrics and more in the industry, it’s important to understand how each group fits into the security process.

    Here are five top tips for security training to successfully implement a DevSecOps strategy.

    Recognize Security is a Shared Responsibility

    Many departments throughout an organization make the mistake of thinking the responsibility of keeping their organization secure lies solely with the security department. However, with nearly 200 cyberattacks happening every hour, it’s important everyone gets on board in protecting applications and networks. As the creators behind our modern-day websites and applications, it’s especially important for developers.

    DevOps and security teams need to be taught how to approach security jointly. When approached separately, it is impossible to achieve DevSecOps. Without DevSecOps, the applications and websites used by consumers everyday will not be secure, and there could be security, quality, legal and reputational implications. Security is now being seen as a fundamental aspect of a consumer’s decision, and consumers gravitate towards brands that are more secure.

    Ensure the Entire Development Team Understands Common Cyberthreats and Application Vulnerabilities

    In today’s world, it is especially important for development and operations specialists to understand application vulnerabilities, and best practices to avoid those vulnerabilities. Without this knowledge, developers and their teams won’t understand just how important security is until it is too late.

    Staying on top of the evolving threat landscape, however, can be a daunting task. After all, there is a lot of information out there. The first step to staying informed is to compile a short list of reliable, valid security news sources. Another step could be creating an internal method for the security team to share details on new vulnerabilities with the development teams.

    Unfortunately, hackers tend to exploit vulnerabilities that were accidentally created by DevOps. In order to fight this, DevOps specialists should be made aware and trained in secure programming, secure application configurations and use of secure frameworks.

    Incorporate Just-in-Time Learning into Your Strategy

    Traditional training courses, especially in the security sector, have some challenges. Many universities and free online resources will offer courses online in cybersecurity. While this can be beneficial in continued training, it can take a significant amount of time to complete the course, and some projects require a certain level of knowledge sooner rather than later. Most courses need to be taken well in advance of a project, where the acquired knowledge will then be applied.

    For example, say developer X just started a course in how to protect from vulnerability Y. At the same time, developer X has a project with code that could be vulnerable to Y due in the next two weeks. With the tight deadline, developer X may not be able to get the knowledge they need to be able to protect their application in time.

    In order to combat this, the security industry now offers real-time learning. Otherwise known as “just-in-time learning,” this approach is giving the employees the much-needed information exactly when they need it. These courses usually come hand-in-hand with using application security testing technology, enabling rapid remediation of a detected vulnerability. For example, when a new security technology is introduced to the organization for development purposes, just-in-time learning would involve developers learning to use it on current projects in real time.

    Avoid Making DevOps Specialists into Security Experts

    While it is important for DevOps practitioners to have knowledge of security best practices, it’s important to remember they should be focusing on their task at hand: creating applications. Security transparency is a critical condition for security adoption by the DevOps team, so it is important the technologies developers rely on are transparent. However, security technologies should not distract DevOps specialists from development and operation. DevOps specialists should be security aware and applying their best security development practices.

    The technologies should test applications and get results to those who need them. DevOps practitioners should then use those results, without having to worry about learning and running sophisticated security detection and protection technologies.

    Remember the Goal is to Educate, Not Embarrass

    Even when using the above tactics, it is still quite possible developers will miss a vulnerability and SAST, DAST, IAST and SCA technologies may discover it first. When this happens, it is easy for DevOps specialists to become embarrassed because their managers see the results first. No matter the experience level, developers will likely at some point make a mistake that can cause a vulnerability–which ultimately gets back to their supervisors and peers.

    Rather than feel embarrassed over the security technologies, developers need to learn how to utilize them to their advantage. For example, modern SAST allows developers to conduct tests out of an IDE and return the test results to the same one. The developer is the only one who will see these tests, and therefore, they can be the one to review and remediate a problem. This process helps eliminate the shame developers feel, and it will instead be replaced with education, security and confidence.

    Cyberthreats are not going away, and all signs are pointing to the fact that they are only going to get more advanced in the future. However, with adequate training and cybersecurity education for development teams, organizations can stay ahead of adversaries and fortify their application security.

    — Joseph Feiman

  • Applying Secrets Management to DevOps

    Applying Secrets Management to DevOps

    DevOps has changed the way enterprises operate, allowing for quick and efficient product development. In order for companies to keep up with market competition, many companies that are not structurally prepared to implement DevOps will still put together a team just to meet demand, which in turn creates vulnerabilities and gaps within their security posture.

    Today, only 46% of IT professionals are confronting security risks during the initial phases of development. With security as an afterthought, DevOps teams may overlook even the most basic security practices. What’s more, in an environment that relies heavily on code, we’ve seen time and time again careless developers leaking confidential information through APIs or cryptographic keys on sites such as GitHub. As a mecca for code, it’s the primary place cybercriminals turn to gain access to the credentials developers have stored in its platform and forgotten to remove before production.

    While GitHub breaches continue to put a spotlight on DevOps security, most organizations are still missing the big picture. The reality is security hygiene remains critical, and DevOps can put their organizations at risk by neglecting basic security practices such as monitoring access and embedded secrets, such as passwords, keys and APIs.

    Where Should DevOps Teams Begin?

    The solution is simple: separate highly valuable secrets from the developer. Luckily, the key to streamlining secrets doesn’t have to be time-consuming or costly. In fact, secrets management is, at its core, an extension of privileged access management (PAM), which many enterprises already have in place.

    As an essential approach to safeguarding an organization against bad actors, one of the fastest ways to mitigate the risk of DevOps-related data is to remediate weak security practices related to PAM.

    The following are some of the most important security protocols DevOps team should apply to their delivery pipelines:

    Inventorying Privileged Accounts and Access

    Large enterprises running networks with thousands of servers and network devices often lack an accurate inventory of assets. Most organizations create a security gap by not understanding the credentials within their systems due to inadequate deprovisioning processes. A DevOps environment’s use of automation and scripts makes it even more complicated to manage privileged accounts and access.

    To ensure DevOps practices are secure beyond the initial provisioning phase, security professionals must understand where automation is stored and what embedded credentials are stored within that automation. By understanding the entire embedded privileged credential process, adamantly keeping track of each DevOps team member’s access and leveraging automation, enterprises can instantly update a user’s access when their role changes to ensure they have the right access to do their job and nothing more.

    Secrets Management Integration

    A significant challenge for DevOps teams in managing privileged credentials is finding a solution that can be seamlessly integrated into existing development toolsets.

    Many DevOps teams rely on several different tools for different phases of the development process, and simply can’t afford to use secrets management solutions and processes that don’t integrate with and address all of them. For example, if an enterprise has invested in AWS and has an Azure-specific secrets management solution, tedious steps could be added to the process. In an environment that’s focused on rapid development, developers are likely to find ways to work around these inconveniences which can put the enterprise at risk.

    To ensure an effective secrets management strategy is put in place, enterprises need to understand that it must work with every tool in the DevOps workflow. By integrating security systems with tools developers know and use, enterprises can ensure no shortcuts are putting its sensitive information at risk.

    Understanding the DevOps Pipeline

    Traditionally, enterprises think the only way to obtain a secret is to log into a server, but in DevOps that’s not the case. In DevOps, when a user with privilege inputs a piece of code, it goes through a pipeline and many enterprises are oblivious to what happens within that pipeline. This blind spot could pose serious cyber risk to the organization. For example, if three developers are working on a project and they check in code that requires privileged access, such as copying credit card information, a developer could inadvertently interject dangerous code into that project and the security team is none the wiser.

    For an environment that’s focused on individualized actions, applying secrets management and thinking twice about who has access to build within this pipeline environment is critical. By not understanding how the pipeline functions and not knowing who has access to specific data, enterprises increase their risk of an internal breach or data leak.

    The reality is managing DevOps security has nothing to do with the actual DevOps process. By integrating basic privileged management protocols, enterprises can ensure security is at the forefront–and not the backend–of the development process.

    — Tyler Reese

  • Trend Micro Partners With Snyk to Advance DevSecOps

    Trend Micro Partners With Snyk to Advance DevSecOps

    Trend Micro today announced an alliance with Snyk through which alerts about vulnerabilities in open source code will be passed on to the tools Trend Micro makes available to apply virtual patches to both monolithic and microservices-based applications.

    Snyk provides a tool that identifies and fixes vulnerabilities and license violations in open source dependencies and container images. Trend Micro COO Kevin Simzer said his company leverages the alerts generated by Snyk to inform developers and cybersecurity professionals where virtual patches need to be applied.

    Virtual patches are a capability Trend Micro developed to enable IT organizations to address a vulnerability by applying a security policy that limits access to a specific piece of code until a developer can update a monolithic application or replace the containers housing vulnerable code within a set of microservices.

    By working more closely with Snyk, Trend Micro is trying to increase the appeal of its approach to virtual patching among DevSecOps teams, said Simzer. It’s not possible for most developers to address every vulnerability that manifests itself in a timely manner. Virtual patching allows DevSecOps teams to establish which vulnerabilities need to be addressed immediately while making use of virtual patches to protect applications from less severe vulnerabilities until they can be addressed during a DevOps cycle. To advance those capabilities, Simzer noted Trend Micro has already integrated its security offerings with continuous integration/continuous deployment (CI/CD) platforms such as Jenkins.

    Simzer said it will take a while for most cybersecurity professionals to trust developers to address cybersecurity issues during the application development process. However, virtual patches provide a mechanism through which both cultures can collaborate more closely without compromising the rate applications are being built and deployed. The primary reason developers tend not to pay as much attention to cybersecurity issues as everyone would like is because of the deadline pressure most of them are operating under. However, as responsibility for application cybersecurity continues to shift left, more developers are trying to address these issues earlier in the application development process.

    More than 16,000 enterprise IT organizations are already using Trend Micro security offerings to secure both monolithic applications and cloud-native applications based on containers, said Simzer, adding that footprint puts Trend Micro in a position to help organizations embrace best DevSecOps practices.

    Of course, Trend Micro is not the only cybersecurity vendor with similar ambitions. The challenge many organizations will face is defining what processes are best handled by developers invoking application programming interfaces (APIs) versus cybersecurity professionals who are more comfortable employing graphical user interfaces (GUI). There may come a day when more cybersecurity professionals are able to write code, but for now the two camps could not be further apart in terms of the tools they prefer to use. For IT security vendors such as Trend Micro, that means for the foreseeable future, they will continue to need to build GUIs alongside APIs.

    — Mike Vizard

  • WhiteSource Extends DevSecOps Reach

    WhiteSource Extends DevSecOps Reach

    WhiteSource has extended its platform that enables developers to more easily address application security issues to provide integrations with GitLab Core and integrated development environments (IDEs) based on the open source Eclipse project.

    David Habusha, vice president of product for WhiteSource, said these latest extensions extend the reach of the company’s platform for addressing DevSecOps beyond existing support for GitHub and BitBucket continuous integration/continuous deployment (CI/CD) platforms and the proprietary IntelliJ IDEA development platform. All of these integrations are being made available via WhiteSource for Developers, a commercial instance of the WhiteSource platform that includes a WhiteSource Remediate tool to address vulnerabilities and integrations with repositories, IDEs, CI/CD platforms and multiple browsers.

    As the responsibility for cybersecurity continues to shift left, Habusha said WhiteSource is making it possible for developers to identify, track and remediate cybersecurity issues from within, for example, an Eclipse-based IDE. That approach eliminates the need developers to exit the tool in which they spend most of their time to address cybersecurity issues.

    In general, Habusha said organizations that have adopted DevOps are now in the best position to leverage best continuous integration practices to make the transition to a new DevSecOps era. It’s still early days in terms of making that transition, but he said it is clear higher levels of collaboration between DevOps teams and cybersecurity professionals are now occurring.

    In fact, a recent survey published by WhiteSource finds 71% of respondents agree that operational responsibility for application security now lies with software development teams. That same survey finds over a third of respondents (36%) are starting to integrate security testing tools at earlier points in the software development life cycle (SDLC).

    Regardless of where organizations may be on the DevOps maturity curve, it’s never too early to address cybersecurity issues. The challenge is providing the means for DevOps teams and cybersecurity professionals to collaborate. There are not enough cybersecurity professionals available to participate in every stage of the application development process. Developers need to be able to act on issues identified by cybersecurity teams within the context of a larger, ongoing quality assurance process that revolves around their CI/CD platform. In effect, Habusha said, responsibility for cybersecurity needs to shift both left and right across the entire DevSecOps team.

    Nor is there any single right approach to DevSecOps; rather, Habusha said each organization will need to define the right set of processes for addressing application vulnerabilities earlier in the development cycle that best fits their culture.

    It may take some time to heal the rift that has existed between developers and cybersecurity teams for decades now. Even though everyone agrees developers need to take on more responsibility for cybersecurity, the individuals within organizations that have cybersecurity expertise don’t always trust developers, who are under constant deadline pressure to do the right thing. However, given the fact that cybersecurity professionals can’t address every vulnerability on their own, many of them are now coming to terms with the fact they need to find a way to work much closer with application developers regardless of their level of trust.

    — Mike Vizard