devopsy.kinsta.cloud

Tag: devsecops

Unleashing the Power of AI-Engineered DevSecOps

In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that AI-engineered tools can help implement the portion of continuous security practices known as DevSecOps.

DevSecOps involves integrating security practices into the DevOps workflow. AI can be used in anomaly detection to identify potential security threats and to automate security policy enforcement. AI-engineered tools have the potential to significantly enhance security across all phases of the software value stream in DevSecOps.

Planning: The planning stage involves dealing with complexities related to risk analysis and threat modeling. AI can help automate risk analysis and threat modeling based on data from past projects and known security issues. This can help identify potential security threats early in the planning phase and develop appropriate mitigation strategies.

Design and Development (prior to integration): Developers often face difficulties in writing secure code, identifying potential security vulnerabilities, and adhering to best security practices while coding. AI-powered static application security testing (SAST) tools can automatically scan the source code for known vulnerabilities and coding errors, providing immediate feedback to developers. In addition, AI could be used to generate recommendations for secure coding practices and strategies for mitigating identified vulnerabilities.

Continuous Integration (CI): Continuously integrating new code can introduce new security vulnerabilities and regression bugs that are hard to catch and fix in a timely manner. AI can be utilized in dynamic and interactive application security testing tools (DAST and IAST) during the integration stage. They can intelligently automate tests and identify complex security issues by analyzing data flows and the behavior of code in an integrated environment.

Continuous Delivery (CD): Ensuring that the code is not only functional but also secure before it is delivered is a major challenge. AI-powered tools can help manage security configurations, monitor changes and alert to any deviations from security policies during the delivery stage. AI can also be used to automate security testing in pre-production environments to ensure that security standards are met before delivery.

Continuous Deployment (to production): Monitoring, detecting and responding to security threats in real-time in production environments is a critical and challenging aspect. AI can enhance security information and event management (SIEM) tools by providing intelligent real-time analysis of security alerts generated by applications and network hardware. AI-based runtime application self-protection (RASP) tools can also detect and block attacks in real-time, providing robust protection for applications in production.

Roadmap to AI-Engineered DevSecOps

It’s crucial to implement AI-engineered DevSecOps solutions in a structured and well-planned manner. Here is a logical roadmap for implementing such a solution:

1. Assessment and Planning: Begin by assessing your organization’s current DevSecOps maturity. Evaluate the existing tools and practices for their efficiency and effectiveness. Identify areas that lack automation or present security concerns. Align the AI-engineered DevSecOps initiative with your business objectives. This includes defining key performance indicators (KPIs) to measure the success of the initiative. Outline the required resources and budget for the implementation. This includes potential AI-engineered tools, the team’s skills upgrading needs and additional infrastructural changes.

2. Selection of AI-Engineered Tools: Based on your assessment, select the AI-engineered tools that best fit your organization’s needs. This selection should cover the entire software development life cycle: Planning, design and development, continuous integration, continuous delivery and continuous deployment. The tools should ideally be scalable, easy to integrate with your existing systems and capable of providing real-time, actionable insights to your team.

3. Training and Upskilling: Train your team on the selected AI-engineered DevSecOps tools. This may require technical training on how to use the tools effectively and how to interpret the insights generated by the AI. Upskill your team to enable them to work effectively within the new AI-engineered DevSecOps environment. This could involve training in AI and machine learning, security best practices and new DevSecOps methodologies.

4. Gradual Implementation and Integration: Start with pilot projects to validate and tweak your approach. The lessons learned from these initial projects will be valuable for the broader roll-out. Gradually implement and integrate the selected AI-engineered tools into your existing DevSecOps pipeline. This should be a phased approach that allows your team to adapt to the new tools and practices.

5. Review and Refinement: Regularly review the effectiveness of your AI-engineered DevSecOps implementation against the defined KPIs. Continuously refine your approach based on these reviews. This could involve adjusting your security policies, refining how you use your AI tools or providing further training to your team.

6. Continuous Improvement: Keep yourself updated with the latest developments in AI and DevSecOps to ensure your approach remains effective and up-to-date. Continually improve and evolve your AI-engineered DevSecOps solution based on emerging technologies, shifting business objectives and feedback from your team.

Avoiding Pitfalls While Implementing AI-Engineered DevSecOps

Implementing an AI-engineered DevSecOps solution comes with several potential pitfalls that can derail the process if not appropriately managed. Here are a few of them, along with suggestions for how to avoid them:

1. Inadequate Planning and Alignment with Business Goals: Ignoring the strategic alignment between implementing AI-engineered DevSecOps and overall business goals can lead to undesirable outcomes. Clearly define the business objectives and how AI-engineered DevSecOps supports them. Outline expected outcomes and key performance indicators (KPIs) that align with business goals to guide the initiative.

2. Neglecting Training and Upskilling: AI tools can be complex, and without proper understanding and training, their deployment may not yield desired results. Invest in training your teams on AI-engineered DevSecOps tools and techniques. Ensure they understand the functionalities of these tools and how to effectively use them. Upskilling your team will be crucial for leveraging AI capabilities.

3. Ignoring Change Management: Introducing AI into DevSecOps is a significant change that can disrupt workflows and resistance from the team members. Adopt a systematic approach to change management. Engage stakeholders from the beginning, communicate the benefits of the transformation clearly, and encourage feedback. Also, plan for a gradual rollout to help teams adapt.

4. Overdependence on AI: Relying too heavily on AI can be a risk if the tools are seen as a complete replacement for human judgment. Recognize that AI is a tool designed to assist human decision-making, not replace it. It’s important to maintain human oversight of AI outputs, as AI models might not fully account for all contextual and situational factors.

5. Neglecting Data Privacy and Ethical Considerations: Using AI requires handling a lot of data, which can lead to privacy breaches and ethical dilemmas if not handled correctly. Develop a clear policy for data management, ensuring compliance with all relevant data privacy laws and regulations. Make ethical considerations a priority when implementing AI, ensuring transparency and fairness in the AI systems.

6. Lack of Continual Improvement and Adaptability: AI-engineered DevSecOps requires a culture of continuous learning and adaptation. Failure to embrace this can lead to stagnation and ineffectiveness over time. Establish a framework for continual improvement. Regularly evaluate the effectiveness of the AI tools and be ready to adapt your processes based on new technological advancements, feedback, and changes in business needs.

Summary

Implementing an AI-engineered DevSecOps solution necessitates a thorough and strategic approach. This begins with an in-depth assessment of your organization’s current DevSecOps maturity and an understanding of how AI can enhance each phase of the software value stream. Essential steps in the roadmap include tool selection, team training, gradual implementation, regular review and continuous refinement and learning. While AI can significantly bolster security and efficiency, it’s important to avoid pitfalls like inadequate planning, neglecting training, resisting change, overdependence on AI, neglecting data privacy and ethical issues and lack of continuous improvement. By focusing on these areas, aligning the DevSecOps initiative with business objectives, investing in team upskilling, managing change effectively, maintaining human oversight, adhering to data privacy regulations and fostering a culture of continuous learning, organizations can successfully implement and maximize the benefits of AI-engineered DevSecOps.

Remember, this transformation won’t happen overnight. It is a continuous journey that requires regular review and improvement. With the right strategy, the benefits of implementing an AI-engineered DevSecOps solution can far outweigh the challenges.

June 16, 2023
It Is Time for DevOps to Focus on Ops

The advent of both Agile development and DevOps were great steps in improving an IT process that had become ossified, with policies that alternated between resistance to change and trying to do things better/faster. Between them, Agile and DevOps broke the cycle of resistance … but only for development.

The confusion around CI/CD is a great example. CD is both continuous delivery and continuous deployment. Do you know why? Because up to that point (and even recently), DevOps included Ops in the name but did little with or for operations. I have no doubt that it was originally intended to include everything from build testing to full-on deployment, and we are finally getting there.

You have no doubt noticed that both operations and security are finally getting DevOps’ attention at critical points. I have been chatting with coworkers about value stream mapping and, if you map the value stream of a software delivery process, you will find that all of the weak points have shifted right. Thankfully, we are also paying attention to them these days.

From GitOps to infrastructure-as-code (IaC); from cloud-first to policy-as-code (PaC), we are finally approaching the operations side with some level of seriousness. And it is generating results for those involved.

My two areas of attention these days are DevOps and application security (AppSec). As I’ve written elsewhere, both are benefitting massively from things like policy-as-code. The ability to apply corporate deployment policies, security policies and compliance policies from a centralized location is massive. It is early days, but community contributions to PaC libraries are already massive, making it easier to deploy without recreating that big old list of generally useful policies.

Given a project, a set of tools and a timeline, you could fully automate the process from the first line of code to running in production, with stops for approval and the specialized steps that still require human interaction (no matter how many public policies are out there, someone with knowledge of your network still has to set up IPs or ranges, for example. Or someone still needs to write the code). Someday, it may be possible to say, “We need a phone app that targets both major platforms and is hosted on Linux that does X, Y, Z,” and it just happens … but we are not there yet, and, IMO, the domain knowledge will be a roadblock for a while. But you can take advantage of what we have to work smarter, not harder. And the organization will be better off for your efforts.

So keep at it, start to evaluate your processes and consider placing any of the great new DevOps technologies into your path. Let them do some of the grunt work so you can focus on adding value. And for all those coworkers that still don’t get it, thank you. You are keeping them in a job, whether they admit it or not.

June 14, 2023
Snyk to Add ASPM Platform via Enso Security Acquisition

Snyk this week announced it plans to acquire Enso Security, a provider of an application security posture management (ASPM) solution that tracks events and analyzes metadata collected from DevOps and security tools.

At the same time, Snyk revealed it has added a DeepCode AI Fix tool that creates validated fixes for code written by either humans or machines and an Insights tool that helps organizations better prioritize remediation efforts based on the risk to the business. DeepCode AI Fix extends the capabilities of a generative artificial intelligence (AI) capability based on large language models (LLMs) that Snyk gained with the acquisition of DeepCode in 2020.

Manoj Nair, chief product officer for Snyk, said all of these initiatives represent an effort to extend the reach of Snyk’s portfolio to address a wider range of issues within the context of a larger DevSecOps workflow as well as give developers tools that enable them to write more secure code.

The acquisition of Enso Security is expected to close this quarter. The company has been making a case for an ASPM platform that eliminates the need to manually collect cybersecurity data from the various tools and platforms that a DevOps team may be using.

Despite innumerable cybersecurity concerns, the rate at which applications are being deployed and updated continues to accelerate. The Enso platform makes it possible for cybersecurity teams to keep pace with those projects by discovering issues before an application is deployed in a production environment.

The challenge, of course, is that most development teams are not going to be able to address every issue before an application needs to be deployed. In addition to knowing who is developing what application code, cybersecurity teams need to also prioritize potential issues versus rather than just sharing a list of potential issues that have been discovered. Enso Security’s ASPM platform provides visibility into events so that it’s simpler for cybersecurity teams to trace issues back to individual developers or the AI platform that generated them.

That latter issue is becoming more significant as more development teams rely on general-purpose generative AI platforms to write code, noted Nair. Those platforms are writing that code based on samples collected across the internet, many of which are deeply flawed from a cybersecurity perspective, he added.

The Enso platform is intended to enable cybersecurity teams to have the most impact on an application development project without being forced to interrogate every developer to determine what’s occurring in any application environment. In fact, one of the reasons developers resent those conversations is they know all the relevant data has already been entered into a system—cybersecurity professionals just need to access it.

There’s still a lot of work to be done when it comes to bridging the historic divide between cybersecurity professionals and application developers. However, the more data that can be seamlessly shared between these teams, the simpler it becomes for organizations to embrace DevSecOps best practices.

June 9, 2023
Coming Soon: AutoOps

I’ve spent a lot of time looking at products in the DevOps toolchain and paying attention to where they are going, what they are doing that is new and how they are differentiated. That has led me to one inescapable conclusion: AutoOps is on the way.

What is AutoOps?

AutoOps is full robotic automation; the continuing progression of what has been building for the last couple of years. We have DevOps, GitOps, DevSecOps, IaC, CloudOps, AIOps … and the list is still growing. But they all move toward one thing: AutoOps.

Now that development has been fully integrated into DevOps, the market is moving to do the same for operations. It is harder with operations because DevOps had Agile, but it is coming. And it is coming to your org.

That is a good thing, in my opinion. Compliance almost demands it; what we currently call AI enables it and staffing in hard macroeconomic times will make it appealing.

The questions that you should start asking now are what does the organization need to enable rapid deployment, management and upgrades while leaving humans in control for the majority of decisions?

Some of you are living this. I have a friend that is in a GitOps shop with automated CloudOps where they are implementing AIOps to handle minor day-to-day things and monitoring for drift … but they’re the exception; most of us are nowhere near there.

Knowing that is where we are heading means you can plan – and it is glaringly obvious this is where we are heading. Vendors are branching from their current subset of XOps to take us there and eventually, we will have a full end-to-end vendor that can do everything from GitOps to fully automated rollout, green/blue deployment, monitoring and drift correction with human intervention only where the organization wants it. Some vendors are already very close to this environment and I expect that several will get there in the next year or two via acquisitions or partnerships.

We just don’t think of the overall DevOps/concept to retirement SDLC process in the absolute terms that AutoOps requires, but we’re going to want to because the environment is changing. The changes are for the better, but they will be massive and cause disruptions. However, they’ll make everything better in the end by eliminating error-producing bits while leaving us in control of the flow and process.

Start Planning for AutoOps

So start planning, understand what your organization wants and needs from the coming full-robotic automation I call AutoOps, and keep kicking rear. Eventually, we’ll have systems that can do a lot of Dev and Ops work, but that day is a ways off, and will require people to manage the systems that manage the systems… Funny but true.

*I’ve never seen AutoOps used anywhere with regards to IT, I just thought it describes where we’re headed pretty well. Let me know if you’ve seen a better term coined by a smarter person. Or a not-smarter person that has a cooler name for it.

June 7, 2023
Atlassian Advances DevSecOps via Jira Integrations

Atlassian announced today it has allied with Snyk, Mend, Lacework, Stackhawk and JFrog to make it simpler to aggregate vulnerability data within the Jira project management software that many organizations rely on to manage application development and deployment efforts.

Andrew Pankevicius, a senior product manager for Atlassian, said the collaborations will make it easier to prioritize a list of vulnerabilities that need to be addressed and for DevOps teams to automatically assign that work to a continuous integration/continuous delivery (CI/CD) pipeline. Atlassian provides those third-party integrations via an Open DevOps initiative.

These capabilities, accessible via the Security Tab in Jira, will make it simpler for DevOps teams to manage output from the multiple application security tools that have become part of a larger DevSecOps workflow, noted Pankevicius.

These additions to the Atlassian portfolio are arriving at a time when there is a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. Those breaches have led to a wave of legislative proposals in the U.S. and Europe that will soon require organizations to embrace DevOps best practices to address increased potential liability that might stem from an application breach.

For example, a proposed Cyber Resilience Act being negotiated by the member states of the European Union seeks to require organizations that sell internet-connected hardware platforms to ensure that their devices—and the software that runs on them—comply with cybersecurity best practices.

In the U.S., meanwhile, a National Cybersecurity Strategy proposal put forward by the Biden administration seeks to hold organizations that collect data or build software more accountable for breaches.

While both proposals are a long way from becoming the law of the land anytime soon, they are indicative of changing attitudes. Governments around the world are concluding the only way to ensure better cybersecurity is to require it. Previous suggestions made by government agencies are going to soon give way to actual mandates. As such, DevOps teams would be well-advised to get ahead of this sea change by implementing the tools and processes that inevitably will be required. As a result, many organizations are now embracing DevSecOps best practices that shift more responsibility for application security further left toward developers.

The challenge is finding the right set of cybersecurity tools that surface vulnerabilities as code is being developed to make sure context isn’t lost, said Pankevicius. Historically, cybersecurity teams have discovered vulnerabilities long after an application has been deployed in a production environment. By then, however, most developers have moved on to other projects, so remembering how a specific piece of code was developed and by whom can be a significant challenge, he noted.

There’s no doubt that when it comes to application security, a lot of progress has been made, but there is still much work to be done. The issue now is finding the best way to organize those efforts at a time when more applications are being simultaneously developed within organizations than ever.

June 6, 2023
The Role of SBOMs in Software Supply Chain Security

The software supply chain has become increasingly complex and dynamic with the rise of cloud computing, open source software and third-party software components and APIs. Widespread damage can occur if third-party APIs, cloud services, SDKs and open source software have security flaws. As a result, software supply chain security has emerged as a critical concern for organizations across industries. Supply chain attacks have become more frequent, sophisticated and devastating, as evidenced by high-profile incidents such as SUNBURST, Kaseya and Apache Log4j.

To address the growing challenge of software supply chain security, organizations have turned to leveraging software bills of materials (SBOMs). SBOMs are a standardized inventory of software components used in a particular product or system, including their versions, dependencies and sources. SBOMs provide transparency and visibility into the software supply chain. They can be an effective approach for identifying and mitigating security risks, compliance issues and operational challenges – assuming organizations have the right tools to fully benefit from SBOMs, including runtime discovery, in place.

SBOMs are not a new concept, but their adoption has accelerated in recent years due to a number of important factors, including the following.

First, regulatory agencies, such as the U.S. National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA), have been advocating for SBOMs as a best practice for software supply chain security. NIST has released a draft guidance document on SBOMs, and CISA has mandated SBOMs for federal contractors and subcontractors.

Second, industry initiatives, such as the Open Source Security Foundation (OpenSSF) and the Software Assurance Forum for Excellence in Code (SAFECode), have promoted SBOMs as a key element of software security. OpenSSF has launched a working group on SBOMs and published the Open Source Software Security Mobilization Plan to improve the resiliency and security of open source software (OSS), including guidelines for SBOM management; SAFECode published a whitepaper on SBOMs.

Third, supply chain attacks have highlighted the need for SBOMs as a proactive and preventive measure. SBOMs can help organizations detect and respond to vulnerabilities, malicious code and unauthorized changes in the software supply chain. SBOMs can also support incident response and recovery efforts by providing accurate and comprehensive information about the affected software components.

Fourth, customer demands and market pressures have influenced the adoption of SBOMs. Customers are increasingly aware of software supply chain risks and are asking for SBOMs as part of their procurement and evaluation processes. Some industries, such as health care and automotive, have mandated SBOMs for safety and liability reasons. SBOMs can also enhance brand reputation, customer trust and competitive advantage for software vendors.

Fifth, technological advancements have facilitated the creation and consumption of SBOMs. The emergence of open standards, such as CycloneDX and SPDX, has enabled interoperability and integration of SBOMs across different tools and platforms. The development of automated tools, such as software composition analysis (SCA) and vulnerability scanners, has enabled the generation and validation of SBOMs in a timely and accurate manner. The integration of SBOMs with other security measures, such as identity and access management (IAM) and security information and event management (SIEM), has enabled an effective view of software supply chain security.

However, SBOMs are not a silver bullet for software supply chain security. They are only as good as the data they contain, and the quality of data can vary depending on the source and the method of collection, particularly around the application software stack of APIs, cloud services and SDKs. SBOM inventory is constantly changing, and being able to leverage their up-to-date data requires more than a snapshot from traditional source code static analysis approaches, but rather continuous runtime analysis and dynamic inventory.

For example, common vendor management and software composition analysis (SCA) approaches often lack source code access for mobile, web, cloud and commercial-off-the-shelf (COTS) software, as well as third-party API services.

For a more effective approach, organizations can benefit from a full-stack attack surface management (ASM) software supply chain solution that delivers continuous third-party application asset discovery and dynamic tracking of third-party vendors. These newer approaches automatically categorize assets under known vendors, allow customers to add additional new vendors, curate individual assets under any vendor, and alert on increases in policy violations and high embed rates of third-party vendors within key applications. These automated capabilities allow vendor management teams to remedy supply chain security problems more quickly and easily and much more accurately than older approaches.

It is important to note that SBOMs also require collaboration and communication among multiple stakeholders, including software vendors, suppliers, customers and regulators. They may also pose some privacy and intellectual property concerns since they can reveal information about the software components and their relationships.

Overall, organizations need to adopt a comprehensive and risk-based approach to software supply chain security, of which SBOMs and tools to best leverage their information are an important component. Organizations should establish policies and procedures for SBOM creation, management and sharing, as well as for validation and verification. Organizations should also integrate SBOMs with other security measures and practices, such as threat modeling, penetration testing and code review to best ensure the security of their software supply chains.

May 23, 2023
Despite DevOps, Software Supply Chain Security Challenges Persist

A survey of 397 IT, cybersecurity and application development professionals conducted by Enterprise Strategy Group (ESG) found that while most respondents work for organizations that have adopted DevOps practices, multiple software supply chain security issues and DevSecOps concerns have yet to be addressed.

The survey, conducted on behalf of Data Theorem, a provider of a platform for securing application programming interfaces (APIs), the survey also found 82% of respondents have adopted DevOps, with 51% reporting they make extensive use of DevOps workflows (51%). Nearly three-quarters (73%) are deploying code weekly and 31% are deploying code daily.

However, securing DevOps workflows remains a work in progress, with 41% reporting security teams lack visibility and control of development processes. Other issues include new builds deployed to production with misconfigurations, vulnerabilities and other security issues (40%), developers skipping security processes (39%), software released without going through security checks and/or testing (38%), lack of security process consistency across different development teams (38%), security team can’t keep pace with release cadences (34%) and developers’ reluctance to work with security (29%).

API security is also becoming especially challenging, with 92% of respondents dealing with at least one API security incident in the last 12 months. Well over half (57%) have dealt with multiple API security issues in the last 12 months.

On the plus side, the survey also found that more than half (54%) of teams responsible for securing APIs are involved with development as soon as or before the APIs are published. A full 97% said developers either have a good (22%) or high level (71%) of API security knowledge. A total of 89% reported their organization provides formal API security training to their development teams. More than three-quarters (78%) can remediate an API vulnerability within a day, and 39% reported they can do so within hours. A total of 60% reported a dedicated budget has been specifically allocated to API security, with another 30% identifying it as a discrete item within their cybersecurity budget. Two-thirds (66%) said spending on API security would significantly increase in the next 12 to 18 months.

The use of APIs is only going to increase in the months and years ahead. Well over one-third (36%) of respondents are using APIs across all their applications, with 50% expecting this to be the case in two years. Another 44% reported most of their applications are using APIs., with 32% expecting this to be the case in two years. More than three-quarters (76%) of organizations reported that they have an average of 26 APIs per application and 53% have more than a quarter of their APIs facing the internet.

More than a third (35%) are updating APIs daily while another 40% do so weekly. A full 61% are using APIs to connect microservices.

Data Theorem COO Doug Dooley said those APIs are now being targeted by cybercriminals that routinely test the weaknesses of every API after each deployment and update. The most common types of API attacks reported by survey respondents included exposure of data (32%), account takeover (31%), denial of service (DoS) attack (31%), attack on misconfigured API (30%), fake account creation (28%), API injection attack (28%), ransomware (27%), data breach (26%) and content scraping (26%).

Despite these issues, however, nearly three-quarters (74%) of survey respondents said they believe their organizations have a robust API security program in place, with 22% reporting they have some process in place. Organizations are using a mix of approaches including API security tools (59%), web application firewalls (WAFs) (57%) and API gateways (50%), distributed DoS mitigation (48%) and bot management solutions (42%).

Challenges included managing multiple tools (29%), visibility into and control of APIs (28%), inventorying APIs (27%), inconsistent adoption of APIs (27%), API security testing (27%), data governance/exposure (26%), discovering and remediating misconfigured APIs (26%), keeping pace with threats (26%) and accurately tracking API usage (25%).

Significant API security concerns included API authentication issues (41%), account takeovers (39%), identifying and tracking third-party APIs (38%), using tools not purpose-built for security (38%), shadow/undiscovered APIs (38%), abusive behavior bypassing app security tools (38%), denial of service attacks (38%), data governance and/or data exposure issues as a result of insecure APIs (37%), abusive behavior bypassing bot management (37%) and outdated/unneeded APIs, also known as zombie APIs. (33%).

The type of vulnerabilities that are of the greatest concern are sensitive data exposure (34%), access control vulnerabilities (31%), API business logic flaws (31%) and DDoS attacks (30%).

More than 79% of respondents, however, are relying on manual testing and review processes to ensure APIs don’t expose sensitive data (79%), with 63% having automated alerting capability for when sensitive data is exposed.

Overall, it’s apparent that more resources as being applied to securing software supply chains in general and APIs specifically. However, given the amount of software being built and deployed, it may be a while before organizations see the return on those investments.

May 18, 2023
DevOps Security: Your Complete Checklist

In a fast-paced environment like DevOps, your security strategy needs to be even more agile. While moving fast is great for delivering application features and functionality, speed shouldn’t come at the cost of security.

DevOps security incorporates security strategies directly into your DevOps pipeline, creating a culture of pre-secured software deployments that work seamlessly for the end user. However, this requires a complete shift in your operational policies and security mindset. You need to start viewing security as an integral part of your DevOps lifecycle instead of a separate department.

Here’s a checklist of DevOps security strategies for your development teams to deliver secure and reliable applications faster:

Your Complete DevOps Security Checklist

1. Analyze your development process for security hazards.
The first step in implementing a DevOps security strategy is finding and fixing loopholes in your existing development process.

For instance, continuous delivery and development are key in a DevOps environment. However, if each change doesn’t go through a code review, it has the potential to break your application.

Deploying changes without passing them through a security checkpoint is like driving at high speed on a road with many curves. Each curve (change) is a potential hazard, and the danger increases when the driver does not know a car is coming from the other side (bug).

Therefore, you must turn the spotlight on your development process and find those curves.

2. Create a common goal between development and security teams.
Traditional roles of developers and security teams might look like they are at crossroads — Developers write code, and security teams find fault with their code. However, in a collaborative environment such as DevOps, security and development must work hand-in-hand to deliver a secure and seamless experience to end users.

Your organization should have a common goal of integrating security directly into the development process. Therefore, encourage open and regular communication between development and security teams. Further, establish joint milestones and review them to ensure there are no silos between both teams.

Once these teams get used to this collaborative approach, your deployments will become faster because fewer things will break.

3. Integrate security procedures in the development phase.
Automation is the lifeblood of DevOps security. Integrating scanning tools into development workflows is critical to your entire process.

For example, automated tools can scan the code, network and infrastructure to identify security vulnerabilities and provide recommendations for remediation. With this, development teams can fix a few security concerns themselves before passing them on to the security team for a final check.

4. Add observability to your pipeline.
One of the biggest challenges of the distributed nature of DevOps operations is visibility. How do you efficiently monitor a large number of operation nodes spread across several different locations?

Observability helps you do this by using logs, metrics and traces—i.e., the outputs of your application to determine internal application health. With observability tools, you can see much deeper into the operations of your systems and identify the exact details of any security concerns. You can also easily identify potential bugs and fix them before they cause problems.

5. Make changes in small, incremental units.
It is infinitely easier to test code in small units and deploy them as minor but incremental changes than handling large, unwieldy blocks of monolithic code. Deploying gradual changes means you can resolve vulnerabilities faster.

6. Scan and secure your entire DevOps pipeline.
A large part of the security hazards in your DevOps process comes from unsecured containers and operations nodes. According to a study from ThreatStack, 94% of organizations say containers represent a security risk.

However, the risk is not limited to containers.

Other services like APIs, third-party tools like Docker and imported code pose a potential security risk to your processes. This makes it necessary to scan all your operations nodes periodically for vulnerabilities. And once you’ve cleared them, remember to lock the door behind you by requiring strict credentials for access to your administrative dashboards.

Ticking Items Off Your DevOps Security Checklist

If you implement most of the security guidelines on this checklist, your organization will have a solid security foundation. However, DevOps security is not a one-time process.

You will need to continuously integrate security protocols into each part of your DevOps life cycle. Furthermore, you will need to re-train your employees and invest in new technology that makes your security pipeline smoother, such as observability.

However, since this entire process makes your applications more secure and compliant while shipping them to market faster, investing in DevOps security is well worth it!

May 17, 2023
AWS Converts Cedar Policy-as-Code Tool to Open Source Project

At the Open Source Summit North America conference today, Amazon Web Services (AWS) announced it is making Cedar, a language for defining permissions as policies that includes automated reasoning to mathematically prove an IT environment is secure, available as an open source project.

In addition, AWS launched SnapChange, an open source fuzz testing tool that cybersecurity researchers can employ to discover vulnerabilities by replaying physical memory snapshots in a KVM virtual machine. Fuzz testing uncovers software security issues by monitoring how the system behaves while processing random data.

David Nalley, director of open source marketing for AWS, said both projects are part of an ongoing AWS effort to contribute intellectual property to the open source community that plays a pivotal role in the applications that organizations deploy on the AWS cloud.

AWS has been employing Cedar to provide IT organizations with the ability to write authorization policies as code that can be deployed anywhere. It is most widely used within the managed AWS Verified Permissions service that manages those processes on behalf of organizations that deploy workloads on its cloud.

Cedar differs from other policy-as-code approaches because it employs automated reasoning, a computer science discipline that is considered a subset of artificial intelligence (AI), to enable machines to prove theorems and checks. That latter capability is especially critical to enable organizations to mathematically prove that compliance mandates have been continuously met, noted Nalley.

Otherwise, IT organizations become wholly dependent on an assessment of intermittent audits conducted by humans that are likely to arrive at varying subjective conclusions, he noted.

The latest open source contributions from AWS come at a time when there is more scrutiny being applied to how open source software is developed and employed. The scrutiny increased in the wake of a series of vulnerability disclosures involving open source software, such as the Log4j monitoring software project.

The maintainers of many open source software projects often don’t have the resources or capabilities required to immediately patch a vulnerability every time it is discovered. That’s become especially problematic, because more research into open source software vulnerabilities is being conducted; it’s only a matter of time before a vulnerability is detected in software that was largely created by developers that have limited cybersecurity expertise. Enterprises that consume open source software need to pay careful attention to what dependencies they are creating when that software gets incorporated into an application environment. A patch for a zero-day vulnerability that is discovered might not be readily available.

Hopefully, consumers of open source software will become more involved in its development by contributing code or making available the financial resources that maintainers need to devote time and effort to creating a timely patch to a vulnerability. In the meantime, however, they should also be reviewing what open source software is included in applications running in production environments. Cybercriminals are increasingly looking to discover and exploit vulnerabilities in not just existing applications but not also in components they know are likely to be employed across a wide range of downstream applications.

As such, finding ways to apply more cybersecurity expertise to application development by embracing DevSecOps practices has become an imperative rather than a recommendation.

May 10, 2023
FIDO/WebAuthn Passkeys is Inevitable: Get on the Train ¦ IBM CEO Hates WFH

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: The Passkeys authentication standard gets a huge boost, and IBM’s Arvind Krishna wants workers back in the office. (more…)

May 4, 2023