Today, economic success depends on digital networking with business partners. This inevitably creates more and more interfaces and thus, greater targets for cyberattacks. The threat situation on the Internet is continuously growing and affects different areas of business and tools. Cybercrime is now more professionally organized than ever before. Attackers use a business model called “cybercrime as a service,” where they don’t even have to develop ransomware, hacking tools, or phishing kits themselves. They can simply rent or buy them, just like regular software solutions. This simplifies access to sophisticated attack techniques, so less tech-savvy perpetrators can carry out attacks.

Cybercriminals are increasingly targeting SaaS business applications with the help of AI tools and deceptively realistic phishing campaigns to obtain access data. In reality, it can look like a seemingly legitimate internal message being sent, for example, on behalf of the IT department. The goal of these attacks is to trick employees into revealing their passwords. These gateways often lead to major security incidents with serious consequences. A successful phishing attack can give cybercriminals access to sensitive company data, which can lead to data theft, financial losses, and even business interruptions.

Although modern cloud platforms have robust protection mechanisms, attackers are also very familiar with them. They use targeted methods to exploit misconfigurations, insecure APIs, and inadequate access controls. Companies shouldn’t just rely on the standard security measures their cloud providers offer. They should also actively integrate cloud security tools into their protection strategy and arm themselves against new and increasingly creative threats.

Let’s take a look at a cyberattack on the British company Marks & Spencer. It became public in April 2025 and cost the fashion and food retailer dearly. The loss of online business alone, which lasted several months, resulted in financial losses of around £300 million (more than €400 million) in operating business, according to a company announcement. M&S shares lost around 3 percent on the London Stock Exchange – an estimated loss in value of more than £200 million. Add onto this considerable damage done to the company’s image and reputation, as personal customer data was stolen.

Three days after the attack was publicized, the company had to stop accepting clothing and home textile orders on its website and app, but by then it was already too late: the impact of the hacker attack on all areas of the company was immense. Stores had to resort to manual processes, using pen and paper in the “old-fashioned” way, logistics costs rose, and food became scarce in some cases. The attack route was manipulated login credentials at a help desk service provider – a classic application security gap (ASG).

Where does the application security gap come from?

Indeed, this is where the main problem lies. Most entrepreneurs feel protected and have never heard of an application security gap. Basically, this significant gap in security configuration and monitoring arises from the problem of responsibility and often goes unrecognized. An in-house IT department can monitor internal processes, but not a cloud-based customer portal or online store. In turn, cloud providers monitor their infrastructure, but not the application connecting them to the company’s internal processes and databases. This creates a security gap: the application security gap. Since most companies now use cloud-based applications, they’re exposed to this potential danger, a digital flank through which attackers can gain access.

Fig. 1: What constitutes the security gap

Applications and cloud applications are attractive to attackers for several reasons:

• They’re directly accessible over the Internet.
• They use cloud platforms and technologies that attackers are also very familiar with.
• They often contain personal or internal company data.

A thorough inventory and analysis can provide insight into the most urgent need for action. Fundamentally, the questions that arise in this context are: Am I aware of the threats to which my application is exposed? Do I understand and use the security features of the cloud platform correctly? If you decide on a cloud solution together with your IT service provider and your company’s internal IT department, you should be aware of the risks and dangers and take appropriate precautions.

Distributed responsibilities: Risky, but necessary

In IT landscapes, there’s often a strict division of labor between development, operations, infrastructure, and security. This has its benefits, as it increases efficiency and takes technical specializations into account. But on the other hand, it often leads to unclear responsibilities. This is especially a problem in cloud-native applications. The infrastructure is monitored by the provider, the business logic lies with the developers, and monitoring – if it exists at all – often focuses on technical metrics like CPU utilization or availability, but not on security-related aspects.

The application security gap is so treacherous because it arises in areas where security responsibility is unclear and it cannot be reliably detected by traditional firewalls or standard intrusion detection systems. Many IT managers rely on certified cloud infrastructure and fail to recognize that application security is explicitly not part of many cloud service level agreements. The combined lack of knowledge about the ASG, distributed responsibilities among several people, and lack of security measures in the DevOps pipeline is particularly dangerous. The latter refers to an absence or inadequate implementation of security mechanisms throughout the software development lifecycle, especially in automated continuous integration/continuous deployment (CI/CD) pipelines typical in DevOps processes.

In detail, this means that in modern DevOps environments, software is continuously built, tested, and delivered. If security aspects aren’t integrated in this process, considerable risks arise. Above all, missing or insufficient security monitoring and errors in the system architecture’s security configuration are the two most obvious application security gap characteristics. Specific examples of these two aspects include:

• Brute force attacks on the application are not detected or reported by the system.
• Multi-factor authentication (MFA) is not used correctly or comprehensively for administrative access.

Typical missing security measures in development and CI

• No static code analysis (SAST): No automated checks are performed for security vulnerabilities in the source code (e.g., SQL injection, XSS, hard-coded secrets).
• No dynamic testing (DAST): Web applications are not tested for attack vectors while running.
• Lack of dependency checks (SCA): Libraries and frameworks are not checked for known vulnerabilities (e.g., via OWASP Dependency Check or GitHub Security Alerts).
• Secrets in plain text: API keys, tokens, and passwords are stored unprotected in the code, in build scripts, or in environment variables.
• No access controls on CI/CD systems: Build systems such as Jenkins, GitLab CI, and GitHub Actions are not secured or have excessive permissions.
• Missing security gates: Security issues do not automatically block builds, therefore insecure artifacts make it into production.
• Untested artifacts: Container images or packages are pulled from untrusted repositories without signing or testing.
• No auditability/logging: CI/CD processes are not traceable, no logs or monitoring by security information and event management (SIEM) systems.

Cloud solutions: Advantages and side effects

The fact is that cloud computing has had a strong upswing in recent years. More companies are outsourcing services, infrastructure, and applications to the cloud to accelerate digitization, scale flexibly, and reduce operating costs. Many features ensure that cloud solutions are a “well-rounded affair.” In fact, studies show that around 45 percent of all companies in the EU use cloud services for standard applications including email, file storage, and office applications. Over 75 percent outsource security or database-related services.

Cloud solutions provide lean IT structures, cost efficiency, maximum flexibility, and speed of innovation in most industries and companies thanks to their high scalability in response to changing requirements and conditions. Cloud services offer a high degree of automation and global accessibility, giving them real advantages over other solutions. However, cybercriminals are also aware of cloud services and their configuration options.

Potential security problems usually don’t lie in the cloud itself, but primarily in how it’s used. Many companies simply underestimate the attack surfaces that cloud solutions open up for hackers. Cloud providers have a shared responsibility model with global reach and enormous network resources (hyperscalers) that make it clear that application security is entirely the customer’s responsibility. Risks for companies can be very high.

• Cyberattacks and misconfigurations: Several cloud migrations have already led to security problems due to inadequate API protection, incorrectly set permissions, and SQL injection attacks. This can result in a highly dangerous cyber threat matrix, including account takeovers and data exfiltration.
• Dependencies on the provider: When critical services (e.g., identity and access management) are managed by the cloud provider, responsibility shifts. The cloud provider controls if there is a security backdoor or if updates are installed on time.
• Unforeseen costs: Improper resource management quickly leads to budget overruns. It’s not uncommon for cloud services running for several years to exceed the originally planned on-premise costs. Many organizations fail to optimize their resources.
• Jurisdiction and data sovereignty: In a globally distributed cloud, it’s often unclear where data is ultimately stored. If a provider stores data in another country, different legal frameworks apply. This can be a problem for international corporations in terms of law enforcement, compliance, and data protection.

However, although non-cloud-based in-house solutions may seem like a secure alternative in light of these risks, don’t be fooled. Most in-house solutions cannot match cloud service capabilities in terms of timeliness, security tools, and monitoring mechanisms.

Large cloud providers have high security standards with many up-to-date tools that companies should use – often in a confusing array. Regular updates offer good basic protection and they can adapt to current risks and threats. A company’s own security remains an internal manner that its IT managers must take care of, but the tools on offer are a worthwhile investment. Yet, this point is often neglected because their secure use requires a great deal of knowledge and organization. And so, it’s come to the point where application security gaps arise.

Digression: Shadow IT, the silent threat

In many organizations a different security risk arises in a completely different place than you might expect: among employees. This is where we encounter the term “shadow IT.” It refers to all IT systems, cloud services, software tools, and devices that employees use in a company without them having been approved by the IT department or management. Shadow IT usually comes from good intentions, like speeding up processes, circumventing complex approval procedures, or adapting workflows for individual requirements.

The desire for greater efficiency, flexibility, and speed is understandable, but the risks outweigh the benefits. A seemingly harmless, unauthorized download that the internal IT department is unaware of can quickly lead to financially and legally risky situations. Security gaps that arise aren’t detected in time because of a lack of monitoring. Shadow IT isn’t just a problem from a security perspective. It has numerous other risks.

Security risks

Many security risks arise, including:

• Increased attack surface: Unauthorized cloud apps operate outside the company firewall and often don’t use multi-factor authentication systems – ideal gateways for attacks.
• Data loss: Unauthorized tools store sensitive data outside secure environments.
• Integration without control: Shadow IT tools can be introduced into existing systems without testing, for example via unsecured APIs, causing critical security gaps.
• Lack of verification: If there is no integration with monitoring, logging, or SIEM, attack windows remain undetected for a long time. No one knows the code or monitors the tool.

Compliance violations

Compliance violations can quickly occur:

• Copyright and licensing issues: Tools are often installed without the correct license. Software manufacturers can demand cessation, damages, or expensive retroactive licenses.
• GDPR and NIS2: Uncontrolled data processing outside of approved platforms risks data protection violations, with fines of up to four percent of the annual revenue.
• Audit compliance and audits: Without a complete audit trail, organizations lose track of things – a classic violation that can lead to severe penalties.

Financial damage and inefficiency

Shadow IT also leads to inefficiency and potential financial damage:

• Duplicate spending: Teams might subscribe to the same SaaS solution multiple times, often at more expensive rates without volume discounts.
• Loss of unused licenses: Automatically renewing unneeded services that are used without the IT department’s knowledge creates unnecessary costs.
• Waste of time and resources: IT teams have to provide unexpected support for unknown tools. Employees spend time using tools instead of collaborating.

Lack of control and governance

Lastly, shadow IT eludes control and governance, which leads to problems:

• Lack of overview: IT departments experience transparency blackouts. In one example, instead of an estimated 20 to 30 tools, around 1,300 unknown applications were discovered on the network. Many of these had serious security vulnerabilities.
• Version and update chaos: Shadow IT tools are rarely patched or updated regularly, so existing security vulnerabilities cannot be closed in a timely manner.

A holistic approach is essential to effectively manage these risks. Organizations need clear guidelines, technical visibility tools, training, and structured license management. This is the only way to ensure long term transparency, compliance, and security for corporate IT:

• Regular shadow IT audits: Use tools like Cloud Access Security Broker (CASB) to discover new services.
• Approval requirement: New creations must be requested centrally and checked against security parameters.
• Training for specialist departments: Raise awareness of structural risks.
• Offer security goodies: Provide central templates, APIs, and PaaS building blocks to avoid shadow IT from the outset.

Digression: Legal frameworks for GDPR, NIS2, and more

The new EU NIS2 directive requires companies from 18 sectors—including IT service providers, digital platforms, and cloud providers—to implement significantly more comprehensive security measures. The scope of application has been greatly expanded: Companies with 50 or more employees or ten million euros in revenue are subject to the regulation. The core requirements include:

• Risk management systems (including supply chain)
• Incident response processes
• Regular security audits
• Training requirements
• Mandatory reporting of serious security incidents within 24 hours

GDPR and application security

Security gaps are also relevant in terms of data protection law, especially for applications that process personal data:

• Unauthorized access = reportable incident
• Inadequate protective measures = risk of fines
• “Privacy by Design” is mandatory

Other relevant standards and frameworks

• ISO/IEC 27001 and 27017 for cloud security
• BSI Basic Protection Compendium
• OWASP ASVS for web application security

Solution approaches: From problem to structured strategy

This raises the question: what specific measures should companies take when it comes to application security? Almost every organization needs to take action in the short term. But it’s important to realize that not every vulnerability can be fixed immediately; priorities must be set.

One thing is clear: cybersecurity only works with shared responsibilities. This is especially true in modern corporate IT landscapes, where numerous applications and tools are used on a wide variety of platforms. Anyone introducing a business-critical application must understand and define who is responsible for that application’s security. Security measured based on this responsibility can be effectively established for each application.

Fig. 2: Shared security responsibility

Immediate measures

Every application owner should first conduct a comprehensive security analysis to identify the biggest vulnerabilities. This includes security checks and threat analyses showing where criminals could strike. Specifically, this means:

• *Tailored security reviews: These ensure that the best security practices for the platform, frameworks, and technologies are correctly established and used. This includes many aspects, including MFA (multi-factor authentication) settings in platforms and clouds, REST API security with OAuth and CORS, security headers in web front ends, k8s security scans with Kubescape, etc.
• Threat modeling for the entire application landscape: The STRIDE analysis method is used to determine in which data flows threats from the STRIDE categories exist (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege). The DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) analysis method is used to determine which risk class the respective threat is assigned to.

Short-term measures

Identified risks should be prioritized and the most important vulnerabilities should be quickly remedied. This closes potential gateways for cybercriminals and helps detect attacks quickly. This means:

• Risky vulnerabilities that can be fixed by code and configuration changes should be prioritized and quickly eliminated.
• Other threats should be addressed through targeted security alerts. These “tripwires” make attempted attacks or anomalies visible immediately, and if necessary, further manual analysis is initiated. Security alerts should be set up step-by-step in a professional SIEM (Security Information and Event Management) tool and form the basis for real security operations.

Medium-term measures

Security operations should be continuously established and expanded for each application, both in terms of tools and personnel. Specifically:

• The security monitoring framework must be continuously expanded and optimized so that current threats can also be detected.
• Automating responses enables a SecOps team to react quickly and effectively in the event of an attack. In the case of cyberattacks, quick action can prevent a large part of the damage.

With a professional SIEM and SOAR (Security Orchestration, Automation, and Response) tool and built-in security dashboards and alerts, a Security Operations Center (SOC) can work effectively, ensure the greatest possible application security, and permanently counter the growing risks of cybersecurity amidst constant change and attack improvements. Companies can staff the SOC themselves or hire a service provider to do so. Outsourcing these services lets even small and medium-sized companies finance the highest level of security.

Fig. 3: Resilience strategies

Conclusion: The application security gap is manageable

The application security gap and cloud solution risk are structural weaknesses that should not be underestimated, but they are not inevitable. If they are identified, addressed, and systematically tackled, the growing threat of cyberattacks can be effectively contained. The decisive factor is not the size of the company, but the awareness that applications and cloud solutions are now the primary level of attack – and must be at the center of any IT security strategy. The fundamental problem of responsibility and the gap between cloud providers and companies must be addressed. Employees should be involved and made aware of issues concerning shadow IT and granting access rights, for example, to documents stored in the cloud.

There is no such thing as absolute security. That would be an illusion given today’s highly heterogeneous IT infrastructures and complex environments. However, those who focus their attention on this issue, use the tools offered by SaaS providers in a targeted and considered manner, and implement a tailor-made, individual solution for their own organization are operating within a secure framework.

What can companies do to build a robust security strategy? Create transparency, monitor threats, and respond flexibly. An important principle is that cybersecurity is a team sport – it only works when all departments work together.

Checklist: How secure is my company?

Do IT risk assessments take the application security gap taken into account?

Is application security systematically and independently checked?

Is there a central register of all web applications and APIs used?

Are responsibilities for applications and their security clearly defined?

Are security tools (SAST, DAST, SCA) integrated into the CI/CD pipeline?

Is there a reporting chain for security incidents in accordance with NIS2 and GDPR?

About the cybersecurity audit: https://www.diva-e.com/de/services/ams/cybersecurity

The post The Invisible Danger: Application Security Gaps appeared first on IT Security Summit.

Software is a basic building material of our modern digital world. The infrastructures which manage our lives, businesses and governments are largely composed of software. The ability to run an organisation is in many ways dependent on our ability to develop and use new software products and services.

The demand for new software grows aggressively with each passing year. In order to maintain competitiveness, enterprise development processes have been squeezed to the point of breaking. In pursuit of ever faster release cycles and ever shorter deadlines, developers commonly overlook basic security steps. Invicti research, 2022 AppSec Indicator showed that 45% of DevSecOps professionals skipped crucial security steps in development to accommodate pressures at their workplaces. On top of that, the code review process – which was meant to catch vulnerabilities made before production – is put under greater pressure as it deals with larger workloads and more vulnerabilities. As a result, many vulnerabilities eventually make it to production.

How AppSec Shifted Left

Shift Left arose to combat exactly this problem. Shift Left declares that security controls in development were placed too far “to the right,” towards the end of the process. Their solution was to “Shift Left,” placing those controls further towards the beginning of the development process, thus catching as many bugs and vulnerabilities as early as possible. In pursuit of that understandable goal, Shift Left adherents introduced Static Scanning technologies to the early stages of development with tools like Static Application Security Testing (SAST) and Software Composition Analysis (SCA) to reveal problems as they arose. That said, solutions to one problem often produce issues of their own.

SAST raises costly false alarms

SAST is one of the central technologies of Shift Left and has also become the primary source of Shift Left’s problems.

Above all, SAST is a notorious source of false positives. One recent review of SAST tools on over 3000 open source code repositories found that 91% of its alerts were false positives.

At the most basic level, this wastes time as teams chase alerts which do little to improve security. These may be simple false alarms or real vulnerabilities, but unexploitable – such as an SQL injection in a piece of internal infrastructure which is only exploitable in one rare case. They might also arise from multiple tools which see the same problem but flag them as separate issues, duplicating the work involved in remediation.

However, they arise, they can quickly become a serious problem. These waste the time, energy and focus of otherwise-rushed specialists who need it to focus on actually mitigating AppSec risk, but it also leaves them open to alert fatigue.

Alert fatigue happens when security teams get tired of false alarms from their scanning tools, they start to disbelieve real alerts and miss the true risks. Many will actually just turn off their SAST tools or just ignore them entirely. This might be the largest problem around SAST: that these produce so many alerts that security practitioners no longer know or care what is dangerous and what is not.

Static Scanning obscures real risks

SAST alerts can commonly be confused with real insights about security. The better way to put it is that SAST scans for and flags mistakes in static code. That is a profoundly useful asset to have, but it does not say whether vulnerabilities are exploitable, whether they’re a risk or offer the context that would reveal how they present risk at runtime.

The “Static” part of SAST offers a clue as to its weakness. Attackers are looking for vulnerabilities in running applications, not static code. The reality of modern cyberthreats is that breaches don’t happen from individual vulnerabilities in static code. Modern cybercrime takes a far more dynamic approach to attacks: they’ll probe APIs, exploit implementation oversights, abuse business logic and chain together vulnerabilities to attack targets. Modern threats live in runtime, and that’s exactly the place that SAST does not scan.

A SAST tool will often flag a vulnerability such as a firewall misconfiguration which an attacker can only exploit in rare and improbable circumstances. It is – on paper – a vulnerability – but it is not a direct threat to an organisation. SAST, however, will not distinguish between that and an imminently threatening vulnerability. If teams can’t distinguish between a high-risk vulnerability and an unexploitable one then they’ll likely waste time and expand risk as they fix the low-risk alert, while neglecting the real vulnerability.

SAST can only be used as part of a broader AppSec strategy, and not its main tool. Shift Left’s true mistake is overfocusing on these kinds of scanning, and the 2-dimensional insights they provide.

Regaining visibility into real risks

Shift Left has helped solve one problem, while creating others. Organisations can’t merely get rid of their static scanning tools but rather have to expand their idea of risk mitigation. SAST and other pre-deployment tools struggle with false positives and lack production insight while neglecting runtime environments – where real threats lurk.

We need to move beyond Shift Left and towards Shift Smart. That means concentrating not on the specific stage of development – but on risk across the whole Software Development Life Cycle (SDLC), putting resources where application risk can actually be mitigated. SAST tells us very little about what happens when an application is deployed in real world conditions, and that’s exactly what AppSec programs need to focus on. Instead, testing needs to be a continuous process occurring across the SDLC. Only then, can AppSec teams get the context to know how a running app actually functions and whether a vulnerability is actually exploitable.

Shift Left has served an important purpose but urgently needs replacing. Shifting Smart will free organisations from chasing arbitrary on-paper vulnerabilities and allow organisations to see where risks actually emerge.

The post How Static Scanning is Eroding “Shift Left” appeared first on IT Security Summit.

Within a single trading day, major security vendors lost billions in market capitalization. Investors were not reacting to a feature update. They were reacting to a possibility: that AI reasoning could challenge the foundations of application security as we know it.

The end of security tools?

The implicit thesis was clear: if an AI system can “understand” code contextually and suggest patches on its own, it could replace core parts of application security. The shift from rule-based analysis to AI-driven reasoning was quickly described as a paradigm change.

In reality, the situation is more nuanced. Claude Code Security does not replace endpoint detection, identity management, or real-time threat monitoring. It operates in the area of code scanning.

Do we really believe that a generalist – no matter how powerful – can dominate a field like IT security, with its established structures and highly specialized tools?

Security has never been just a pattern recognition problem. It has always been a matter of human judgment.

Tools remain valuable

In his Nicomachean Ethics, Aristotle distinguished between episteme (theoretical knowledge), techne (practical skill), and phronesis – practical wisdom, the ability to make sound decisions in concrete situations. Security operates exactly in this space: incident experience, regulatory requirements, industry-specific attack patterns, operational resilience – all of this has been condensed over years into specialized tools. These systems are not just code; they are experience embedded in code.

In interviews with industry leaders, it becomes clear that even from a pro-AI perspective, the discussion is not about replacement, but about use. Jensen Huang, CEO of Nvidia, puts it simply: “Agents won’t replace the tools, but agents will use tools.” And he adds: “Why rewrite the browser when the browser exists and just use it?”

Tools exist for good reasons. They bundle knowledge, structure decisions, and encode implicit heuristics. Agents will increasingly use these tools – but they will not make them obsolete.

There is no doubt: AI supports security experts

In practice, AI accelerates threat modeling, supports code reviews, analyzes dependencies, and detects anomalies. In well-structured environments, a clear leverage effect appears: expertise is amplified, routine work is reduced.

The key question, however, is who takes responsibility. Risk acceptance is not a statistical function, and liability is not a feature of a model. AI can strengthen expertise – but it does not replace the instance that ultimately carries responsibility. This distinction is discussed in sessions such as May the Code Be Secure and in the full-day workshop Secure Your GitHub Pipeline at our IT Security Summit in June 2026. The focus there is not on the next tool, but on integrating AI into existing responsibility structures.

When Security Becomes an Architectural Question

This broader shift is also visible in the latest OWASP Top 10, the 2025 edition. Topics such as software supply chain failures, insecure design, and deficiencies in logging and alerting dominate. These are no longer isolated vulnerabilities; they are architecture and process issues.

Security emerges in architecture decisions, in external dependencies, and in the way services communicate with each other. It is not a single event, but a continuous state within the overall system.

If security touches architecture, an organizational consequence follows. Supply chain, infrastructure, and observability affect multiple disciplines. Security specialists become co-designers – working alongside architects, developers, and operations teams. DevSecOps is therefore a response to systems that cannot be secured by isolated teams.

Service Mesh – infrastructure for collaboration

This collaboration can also be anchored in infrastructure. A service mesh, for example using Istio Ambient, makes mTLS the default, enforces zero-trust principles at platform level, enables centralized policy enforcement, and creates transparent observability. Security is not simply added at the application layer; it is implemented within the system itself. In the two-day Service Mesh bootcamp led by Michael Hofmann, this shift is explored in practice. 

AI agents – diligent assistants

Autonomous agents operate across system boundaries and use existing tools. Attacks increasingly unfold across systems. Governance becomes central: Who defines policies? Who is responsible for machine identities? Sessions such as Ensuring Security and Compliance in the Cloud by Governing Autonomous Agents and Threat Modeling Agentic AI Systems Across Five Threat Zones at the IT Security Summit address exactly these dynamics. Security becomes a continuous design task as systems change, scale, and interact across boundaries.

What remains constant is responsibility

Security 2026 operates in systems that are more complex, more connected, and supported by increasingly powerful tools. AI accelerates many processes – it changes the methodology and economics of software security. What remains constant is responsibility: grounded in judgment, anchored in architecture, organized in collaboration.

The IT Security Summit is not a showcase for individual technologies, but a forum to discuss exactly these interconnections.

The post Will AI Replace Cybersecurity? appeared first on IT Security Summit.

Imagine giving someone a chainsaw and expecting them to create an intricately carved wooden bear overnight. In North Gloucestershire, where I live, you can see beautiful chainsaw carvings of owls and bears at roundabouts – testament to what these tools can achieve in skilled hands. Yet, we wouldn’t expect to leave a chainsaw in our garden overnight and magically find a perfectly carved ornament in the morning.

This analogy perfectly captures the first death of application security between 2005 and 2008. In sleek Silicon Valley conference rooms, people dreamed of creating self-healing software – applications that could automatically repel attacks without human intervention. The result was static analysis tools that, while technically impressive, effectively became chainsaws in untrained hands.

These tools could tear through code and find thousands of vulnerabilities but with false positive rates that would make a Vegas gambler think twice – they created more harm than good. The fundamental flaw wasn’t in the technology itself but in our approach to deploying it. These early pioneers believed developers would embrace tools that essentially told them “you suck at your job,” even expecting them to reach into their own pockets to buy this technology. This naive assumption set the stage for fifteen years of friction between security and development teams.

The Second Death: Security by Maturity Models and Security Gates

The 2008 financial crisis marked the second death of application security, forcing a dramatic pivot in the industry. Venture capitalists called emergency meetings, demanding 30% headcount reductions and a shift to operational profitability. The industry responded by falling back on what it knew from quality assurance: Maturity Models and Gates.

This era saw the rise of elaborate maturity models like OpenSSAMM and BSIMM with 173 points of measurement. While these models appeared to create value, they ultimately introduced friction.Organisations built massive security gates, believing they could simply tell developers “your code shalt not pass” until security requirements were met. The approach seemed logical but ignored the fundamental realities that software development had moved on from annual releases to agile methodologies and multiple releases per hour, per day or per week.

The most damning evidence of this approach’s failure comes from Veracode’s Annual State of Software Security Report: the mean time to resolve critical vulnerabilities increased from 220 to 290 days. Think about that – nearly a full year for attackers to exploit known vulnerabilities. We had created a system that prioritised measurement over remediation.

The Third Death: The Opioids of Static SCA

The third death arrived with President Biden’s executive orders on supply chain security and software composition analysis. While well-intentioned, these mandates became what one might call an “opioid for application security teams.” Security teams could keep busy updating libraries and moving dashboard needles without addressing fundamental security issues.

This approach ignores a crucial reality: if you’re not calling a vulnerable dependency at runtime, its vulnerability doesn’t matter. The Log4j incident perfectly illustrated this problem – organisations spent weeks scrambling to identify vulnerable instances, often without understanding whether these instances were actually exploitable in their environment.

The Half-Death: Heath Robinson and Application Security Posture Management

The attempt to unify various security tools under a single dashboard represents what we might call a half-death – the beating heart within a corpse. First attempted by HP in 2011 with the Fortify and ArcSight integration, these efforts promised to bring together static analysis, dynamic testing, SCA, Infrastructure as Code under a single pane of glass. This is also known as Application Security Posture Management.

However, these integration efforts failed to address the fundamental issues of feedback loops and developer enablement. They simply created another layer of abstraction without solving the underlying problems of accuracy, timeliness, and relevance.

Part 2: The Rise of Real Threats and Self Protecting Applications

While we were busy building gates and measuring compliance, the threat landscape was evolving dramatically. Attacks like WannaCry and NotPetya demonstrated ransomware’s devastating potential, causing billions in damages and disrupting critical infrastructure globally. Cybercriminals adopted sophisticated tactics including double extortion, where data is stolen before encryption.

Next-Gen EDR and SIEM solutions emerged as effective countermeasures by incorporating AI-driven behavioural analysis, automated response capabilities, and real-time threat detection. These tools can identify ransomware’s pre-execution indicators, stop lateral movement, and provide comprehensive attack chain visibility. Enhanced capabilities like rollback features and isolated environments have significantly reduced ransomware’s effectiveness in protected environments.

While we owe our thanks and congratulations to these organisations and companies, a 2023 RedSense report revealed an unexpected trend: traditional ransomware attackers are suffering. Not because they’ve become ethical and upstanding citizens, but because endpoint security has become effectively hardened against their attacks.

This has pushed sophisticated attackers toward a more lucrative target: applications and APIs. Consider a nation-state actor targeting a car manufacturer. They’re not interested in hacking cars; they want the intellectual property behind building car plants – a multi-billion dollar economic advantage. These attackers play the long game, assembling teams of specialists who might spend two years crafting SQL injections or finding ways to compromise Web Application Firewalls (WAFs).

The scary part? Our current security approach gives these attackers plenty of time to operate. With a 290-day average remediation time for critical vulnerabilities, attackers have nearly a year to exploit known weaknesses. Even more concerning, many organisations rely on WAFs as their primary defence, despite well-documented vulnerabilities in these systems dating back to 2010.

Industry, our businesses and our communities deserve a superior approach to thwarting these attacks. Application Detection and Response (ADR) is such a response. It represents the death of AppSec 1.0 and the rise of self-protecting applications.

ADR: Runtime Intelligence as the Way Forward

Application Detection and Response (ADR) represents a fundamental shift from theoretical vulnerabilities to real threats. Instead of throwing chainsaws into organisations, we’re creating intelligent systems that can watch for and respond to attacks in real-time – like surveillance teams in spy movies, watching bad actors move through a city until they make their move.

This approach focuses on runtime behaviour, watching for malicious code as it attempts to exploit vulnerabilities. Like a team of surveillance experts tracking a suspect through city streets, ADR systems observe code execution, watching for suspicious patterns and blocking attacks before they can succeed.

The beauty of this approach lies in its context. When you can show a developer their code under active attack from bad actors, the motivation to fix issues becomes real and immediate. This isn’t about compliance or theoretical vulnerabilities; it’s about protecting real assets from real threats.

The Economics of Modern Security

Accelerating Revenue Through Faster Deployment

In today’s digital economy, speed to market often determines market success. Traditional security approaches force development teams to slow down for security reviews, vulnerability remediation, and compliance checks. Every day of delay in launching a new feature or product has a quantifiable cost in lost revenue and market opportunity.

ADR transforms this dynamic by embedding security directly into the development and deployment process. When security becomes a real-time function rather than a series of gates and checkpoints, development teams can move at full speed with confidence. Organisations typically see deployment cycles accelerate by 30-40% , translating directly to faster revenue realisation and improved market competitiveness.

Cyber Resilience in Real Time

The risk equation in modern business extends far beyond simple vulnerability metrics. When nation-state actors spend two years crafting attacks to steal intellectual property worth billions, traditional security approaches are woefully inadequate. ADR addresses this by providing real-time threat detection and response, protecting not just against known vulnerabilities but against active attacks as they occur.

This capability transforms how organisations manage risk. Instead of theoretical vulnerabilities that may or may not matter, security teams can focus on actual threats targeting their critical assets. The business impact is substantial: reduced insurance premiums, improved customer confidence, and protection of vital intellectual property that drives competitive advantage.

Enabling Digital Transformation

Digital transformation initiatives often stumble when they hit security roadblocks. Traditional approaches create a fundamental tension between transformation goals and security requirements. ADR resolves this by making security an enabler rather than a blocker of transformation efforts. Organisations can now modernise their application portfolio faster, adopt new technologies with confidence, and accelerate their cloud migration initiatives. The business impact extends beyond security metrics – organisations see improved customer satisfaction, faster innovation cycles, and better ability to compete in rapidly evolving markets.

Conclusion: Breaking Free from the Past

The death of traditional application security isn’t a tragedy – it’s an opportunity to build something better. Through ADR and runtime intelligence, we can finally deliver on the promise of secure software development, protecting not just code, but the intellectual property and innovation that drives our digital economy forward.

The future of application security lies not in more tools or more processes, but in intelligent, context-aware systems that can protect applications in real-time while enabling developers to build secure software faster. By learning from our past failures and embracing this new paradigm, we can finally break free from the cycle of death and rebirth that has characterised application security for the past two decades.

The traditional model of application security as a cost centre is dying. In its place, ADR offers a new paradigm where security becomes a business enabler, driving value through faster deployment, reduced costs, better risk management, and improved operational efficiency.

For organisations undertaking digital transformation initiatives, the choice is clear: continue with expensive, ineffective traditional approaches, or embrace ADR as a catalyst for business transformation. The impact extends far beyond security metrics to the fundamental drivers of business success in the digital age – speed, efficiency, innovation, and customer trust.

The transformation of application security from cost centre to value driver isn’t just possible – it’s imperative for organisations that want to compete and win in today’s digital economy. Through ADR, we can finally align security with business objectives, delivering protection while enabling the speed and agility that modern business demands.

The post The Three and Half Deaths and Rebirth of Application Security: From Chainsaws to Application Detection and Response appeared first on IT Security Summit.

How did security debt reach crisis levels?

Before we delve into the ways to reduce security debt, it is important to reflect on how we got here. The main reason behind the mounting security debt is that organisations are not prioritising or focusing on fixing the flaws that pose the greatest risk: the critical ones.

Application age and size play a significant role in the accumulation of security debt. We have repeatedly observed a recent bias in the way developers fix security flaws: the more time that passes from a flaw appearing, the lower the chance it will ever be fixed. Recent research found that 42% of all flaws roll over to become security debt, so the older the app, the higher the debt accumulation.

Looking for advanced methods to reduce Cybersecurity risks?

4 days of Keynotes, Sessions & Workshops in Munich, December 1 - 5, 2025

Discover now

Application size is also key. As the codebase of most applications grows over time, it is only logical that there is a correlation between age and the accumulation of older, unremediated flaws. Large applications therefore have the highest proportion of security debt, with 40% of them having security debt, and 47% having critical debt. And while it is not always the youngest and smallest apps that have the least debt, older monolithic applications present a greater challenge.

Flaws in open-source third-party code tend to become security debt slightly faster than first-party code. What’s more, third-party flaws tend to emerge continuously as new vulnerabilities are discovered by security researchers. This means that unless organisations keep their libraries up to date, applications will accumulate more and more risk as time passes, even if nothing has been added to the codebase.

Another major factor contributing to an organisation’s compounding debt is the increased use of generative AI to write code – a practice that will only increase over time, with Gartner predicting 75% of enterprise software engineers will use AI code assistants by 2028. Using AI is not a problem in itself. AI-generated code is not inherently less secure than human-generated code, but it’s also not more secure. The problem is an over-reliance on AI and the erroneous assumption that it will automatically produce properly functioning, flaw-free code. Large Language Models used to generate code are often trained on insecure open-source projects and other publicly available code, meaning AI-generated code can be insecure as well. Failure to vet this code properly adds to an organisation’s security debt over time and may even accelerate security debt as AI helps developers code faster than ever.

It is also important to note that security debt is not solely the result of mismanagement, poor decisions, or failure to execute. Time and resource pressures mean developers and product managers must decide which flaws to fix and which to let lie.

Easing developer pressures with AI

Thankfully, innovation is slowly lifting the pressure on development teams. New technologies like AI, when implemented with appropriate safeguards, allow developers to address more flaws and avoid spreading their time and resources too thin. AI has already fundamentally changed the paradigm of future business. Although it may seem counterintuitive based on the aforementioned risks, we are in an age where we need to consider fighting AI with AI.

Let’s consider the role that AI should play in both creating and safeguarding our software. AI can make the dream of accelerating code fixes a reality; however, it’s up to us to harness its power responsibly.

AI-driven tools, particularly those based on GPT models with supervised training on curated security-specific datasets, excel at cybersecurity tasks. These models can provide highly reliable flaw remediation suggestions, ensuring that vulnerabilities are addressed promptly and effectively. However, it is crucial that any tool handling source code, especially for security purposes, maintains the highest standards of data integrity and security.

Incorporating AI into the software development lifecycle not only enhances efficiency but also has the potential to fortify the security posture of applications. By identifying and addressing vulnerabilities early, development teams can deliver robust, secure software that meets the ever-evolving demands of the digital landscape.

From awareness to action: How AI can supercharge flaw remediation

Being aware of a flaw is not the same as fixing it. That is why frequent code scans do not always correlate with less debt. Knowing is only half the battle; the other half is doing something about it.

Continuous scanning must come with continuous fixing, but even the biggest teams with ample resources typically do not fix all their flaws. The problem has grown beyond the ability of humans alone to manage it, so AI-powered tools are becoming necessary. Despite fears from many that it could be a threat to security, the truth is Artificial Intelligence is increasingly part of the solution to help developers fix more efficiently.

Leveraging AI, developers can shift security left in the development cycle, meaning they identify and fix vulnerabilities as they write code. This proactive approach allows organisations to detect and address potential security risks at an earlier stage, reducing the likelihood of costly and time-consuming issues later down the line.

Shaping a safer future with faster, smarter code fixes

As AI reshapes every facet of technology, its role in addressing security debt stands out as both an urgent need and an unparalleled opportunity to reverse a currently spiralling trend. By shifting security left and enabling developers to detect and remediate flaws earlier, AI has the potential to turn the tide on security debt accumulation.

In the coming years, software security must evolve from simply identifying vulnerabilities to preventing them at the source. Empowering development teams with AI-driven tools trained on robust security datasets could redefine software security, enabling scalable, secure coding practices. In this new paradigm, AI becomes not just a tool for remediation but a cornerstone for building a safer, more resilient digital future.

The post The Growing Threat of Security Debt: Exploring AI’s Role in Remediating Persistent Software Vulnerabilities appeared first on IT Security Summit.

Impersonation attacks can be implemented on several communication platforms, including social media, email, websites, SMS, voicemail, and even the phone. They can also involve misleading targets with scams executed through spoofed domains, fake mobile apps, phony social media accounts, and so on.

Email Impersonation and Spoofing

Cybercriminals send an estimated 3.4 billion emails daily, designed to look like they come from trusted senders. That’s not all: Email impersonation makes up an estimated 1.2% of all email traffic globally. Email impersonation occurs when cyber attackers create emails that seem to originate from a legitimate source by imitating the sender’s name, address, and writing style. In email spoofing, the header is forged. The goal is to make the email look as authentic as possible to convince the receiver that it’s from a trusted source or a reputable organization.

Executive Impersonation (CEO Fraud)

As the name suggests, this is business email compromise (BEC), in which criminals pose as high-authority executives of reputable organizations. They send emails to employees with urgent requests for money or sensitive information, using the combination of urgency and authority to pressure the receiver to comply without authenticating the request.

Looking for advanced methods to reduce Cybersecurity risks?

4 days of Keynotes, Sessions & Workshops in Munich, December 1 - 5, 2025

Discover now

Account Takeover (ATO)

In this case, attackers gain unauthorized access to a legitimate user account, usually through phishing or credential theft. They then send emails to other people from this account, making the communication appear authentic. These emails typically ask receivers for sensitive information or initiate fraudulent monetary transactions. Because the emails are thought to come from a reliable source, receivers tend to comply and get defrauded.

Social Media Impersonation

Cybercriminals set up fraudulent accounts to impersonate high-ranking executives employed by well-known businesses or financial institutions. These phony social media accounts can defraud people, steal confidential data, or manipulate victims into giving away their credentials to unlock secure systems. This can ruin the executive’s and company’s credibility and cause severe reputational damage.

Voice and Video Impersonation

Approximately 70% of people say they aren’t confident they can tell the difference between a real and cloned voice. No wonder cybercriminals are exploiting generative AI to clone voices and produce images/videos to scam others! This is done by creating short audio and video clips using content obtained from public sources or social media. The final goal of voice and video impersonation is to gain access to private information or secure systems.

Prevention Strategies

Alarmed? We won’t be surprised. Mentioned ahead are a few effective ways to protect individuals and organizations from becoming victims of impersonation attacks.

Human Firewalls

Educating people and spreading awareness about the perils of impersonation attacks can help curtail them to some extent. This means conducting regular training sessions that focus on ways to identify suspicious requests, their verification, and best practices for using sensitive data.

Employees should know how to be vigilant and examine email addresses closely before opening them, clicking on links, or downloading malicious attachments. Organizations looking to thwart impersonation attacks must be mindful of the following:

• Avoid any emails that contain suspicious attachments
• Report unusual transaction requests, like making huge wire transfers or buying gift cards in bulk
• Flag any email received from strange locations, especially if it comes at an unusual time of the day
• Report requests for financial details or identification
• Filter emails from unknown addresses and senders

Together, these practices help create a human firewall where employees become well-equipped defenders against cybersecurity risks. As the last line of defense against cyber threats, your company’s human firewall will proactively check for potential attacks or malicious emails and report suspicious activities to the concerned authorities before the situation spirals.

Website Verification

Cybercriminals are now setting up fake websites that closely resemble those of reputed companies in design and name. These fake websites are actually phishing websites created to steal a user’s login credentials or credit card information. While there’s no way to prevent this kind of website spoofing, organizations can still take necessary steps to safeguard themselves and their customers.

Companies must set up alerts for newly registered domain names that are similar to theirs. Website verification can help here. Real-time monitoring of spoofed websites is key. Organizations can leverage AI-based threat intelligence solutions that scan the internet for domain name spoofing and website cloning. Once detected, they alert companies to take immediate action against them.

A tool like Memcyco, for instance, that provides real-time protection against impersonation attacks, can alert organizations when their website is spoofed and issue red alerts to visitors. These warnings will continue until the phony website is taken down. This simple step can ensure that companies preserve their reputation and security while retaining the faith of potential customers.

Advanced Email Security

Advanced email security solutions use machine learning algorithms to identify phishing attempts. They harness real-time threat intelligence to detect and block malicious emails and use sandboxing to evaluate suspicious attachments.

Organizations can use anti-impersonation techniques like DNS (Domain Name Server) authentication, which are equipped with protocols such as:

• DMARC (Domain-based Message Authentication, Reporting, and Conformance)
• DKIM (Domain Keys Identified Mail)
• SPF (Sender Policy Framework)

These protocols can detect and mitigate phishing attempts while blocking spoofed email addresses.

Monitoring and Quick Response

One of the most effective ways of preventing impersonation attacks is by leveraging machine learning tools that aid constant monitoring for unusual activities. A swift incident response plan should be the natural next step. This includes eliminating any fraudulent infrastructure mimicking your business.

Continuous monitoring will help you locate the impersonation and submit a takedown request to the concerned website host or social media platforms.

You can also proactively destroy attempts to create spoofed domains, fake social media accounts, or even fraudulent apps before the impersonation attack can reach your employees and/or customers.

Secure Communication Practices

Following secure communication practices involve double-checking website names, social media handles, and email addresses, especially if you suspect something.

• Verify the sender’s identity before responding to any unusual requests for information.
• Type URLs directly into the web browser’s address bar instead of clicking on an email link.
• Double-check the destination URL before clicking on an embedded link.

If you’re unsure about an email’s authenticity or detect any suspicious activity, report it to your company’s IT department immediately.

Wrapping Up

As you can see, technological innovations can be both a boon and a bane, like impersonation attacks. Fortunately, companies and individuals can take preventative and remediation actions to avoid becoming victims and curb their losses. Hopefully, this post will help you understand, identify, and avoid malicious attacks, safeguarding your organization’s reputation and credibility among customers.

The post 5 Types of Impersonation Attacks and Ways to Prevent Them appeared first on IT Security Summit.

Four areas to hone in on

The challenge around software supply chains is that every organisation has different security processes in place. These processes may vary based on how large each organisation is, how many developers it has, what software they use, and how well various teams collaborate.

There are four primary risk areas, security concerns, and potential attack approaches regarding software supply chains that you should be aware of.

1. The risk of using malicious software packages

Threat actors can compromise software libraries or packages that your organisation uses for any number of applications. This malicious package would be bundled into your application each time it’s compiled, including malicious code in each software update. Over time, this could be spread and exploited by that initial threat actor, or potentially even others.

For instance, this might look like a threat actor creating compromised packages on the npm JavaScript registry that mimics real packages.

2. Threat actors attempting to compromise an entire code repository

This involves injecting malicious code alongside existing legitimate software, and then waiting for it to make its way into unsuspecting users’ environments.

For example, threat actors might copy a very popular repository and only slightly alter its name (typosquatting) and code in the hopes that the difference would go unnoticed and mistakenly downloaded by an unsuspecting developer.

3. Third-party exploitation

Related to the attack vendors above, third-party exploitation means your software provider itself has been compromised. A threat actor has gained access to their network and may use their tool or environment to access their end users, including your organization. By gaining access to one company, attackers can target multiple others. This differs from a software package attack because you likely do not have full visibility into your third-party provider’s software, and it also presents more risk because you’re placing trust in your vendor’s software security versus internally developed software.

An example here would be the SolarWinds breach, where the company’s software was compromised and subsequently used to infiltrate several large enterprises and government organisations.

Looking for advanced methods to reduce Cybersecurity risks?

4 days of Keynotes, Sessions & Workshops in Munich, December 1 - 5, 2025

Discover now

4. Attackers may try to get their code contributed and included within open source software

This is the long-con approach based on social engineering tactics and attacks against project maintainers, where the attackers look to build trust and gain direct access to the project then add their own code.

The attack on XZ Utils, a data compression utility included with most Linux distributions, where obfuscated code was created and inserted after a committer spent years getting embedded and trusted within the community would be an example of this supply chain security risk.

How to protect your software supply chain and security benefits

Defending against these attacks requires a complete understanding of how your organization’s software development lifecycle works and how projects move from start to finish. Once you can confirm there are continuous integration and continuous deployment (CI/CD) pipelines in place and that infrastructure as code (IaC) is used to automate deployments, building best security practices earlier into the software development lifecycle will help ensure security risks are caught before they become potential issues.

For internally developed applications, building security as code (SaC) and policy as code (PaC) practices into your IaC templates will also help enforce security policies and checks at each stage of the CI/CD pipeline.

Using IaC security measures has two benefits: First, it ensures that every developer and IT professional who works with infrastructure understands and sees the policies in place because they are all cemented in code.

Second, implementing “anything as code” makes it easier for developers to enforce policies throughout an environment without fear of missing a step or wasting unnecessary time, and it’s also easier for developers to hone in on and remediate policy errors.

In the event of a supply chain attack, when a malicious component accidentally gets embedded, it may pass your coded policy checks. After all, that package is from a known source, so why would it be considered a risk? At this point, runtime security scanning is essential to your security process. A runtime scanner looks at the behavior of every software component as it is executed in production. From a security perspective, this focuses on what components actually do rather than what they may say they will do. Now, if and when a suspicious library starts acting outside its normal parameters, that activity can be immediately flagged for investigation.

For third-party software packages, getting that deep insight may not be possible, as many applications are provided as binaries to run rather than full collections of containers and their dependent libraries.

To work around this, you can ask during business negotiations for software bills of materials (SBOMs) that list included components – while many companies don’t yet automatically provide SBOMs for their systems, it is slowly being regulated into becoming the standard. It is required for any company providing software to the US Government, and it is mandated in the EU’s Cyber Resilience Act. In any case, checking security processes and accreditations can also help demonstrate that your supplier follows security best practices in their environments.

However, relying solely on what your vendor says they will do is still not enough. A runtime security tool also looks at what is actually happening within applications and can track that behavior over time. Similar to monitoring your internally created applications, knowing what that third-party application should be doing and looking for deviations can indicate potentially malicious activity where the software may have been compromised.

Plan ahead

Good security always starts with planning. Keeping your software supply chain secure involves looking ahead and understanding how your system would handle potential attacks. Once you have conducted a threat model or tabletop exercise with your developers and other stakeholders, you can work together to build security autonomously into the software lifecycle.

But before you run off, you cannot rely on this initial design work to secure your whole system. While it might be nice to think that this extensive preparation will keep your whole pipeline secure in the long term, the reality is that security is messy. However, by looking at both sides of the software pipeline – from initial development through the supply chain to your production deployments – you can comprehensively harden your environment.

Using a runtime security tool for real-time threat detection ensures you know when something is wrong in your production environment and equips you to fix or mitigate those potential vulnerabilities as they arise. This real-time, runtime security approach is your last line of defense, and it also complements the layers of security that you have already factored in.

No software supply chain is perfectly secure but with runtime security, you can get close.

The post Securing Your Software Supply Chain: Four Key Areas to Consider appeared first on IT Security Summit.

Gefahr durch Eingaben

Sicherlich ist der erste und wichtigste Schritt, sämtliche Variablen, die durch Formularfelder befüllt werden, auf eine gültige Eingabe hin zu prüfen. Ein gängiges Mittel ist die Validierung über reguläre Ausdrücke, die sicherstellen, dass nur gültige Zeichen und ein korrektes Format zugelassen werden. Möchte man aber beispielsweise formatierte und umfangreiche Artikel ermöglichen, wie es bei einem Content-Management-System der Fall ist, haben die gängigen Schutzmaßnahmen durchaus ihre Schwächen. Denn das Prinzip, möglichst die Eingabe zu beschränken und gefährliche Zeichen herauszufiltern, hat bei formatiertem Text seine Grenzen.

Wollen wir beispielsweise ein Zitat in Anführungszeichen setzen, können wir die beiden Zeichen ‘ und “ nicht einfach aus dem Text entfernen, da diese ja Bestandteil des Inhalts sind. In der Vergangenheit nutzte man bei dieser Problematik einen zusätzlichen Mechanismus, um Schutz vor Cyberangriffen sicherzustellen. Hierfür werden sämtliche kritische Zeichen wie spitze Klammern, Anführungszeichen und Backslashes über ihre HTML Escapes ersetzt. Damit gelten diese als problematisch klassifizierten Sonderzeichen nicht mehr als Quellcode, da aus > ein &gr; wird. Daher sind die soeben beschriebenen Maßnahmen besonders wirkmächtig und bieten bereits einen effektiven Schutz.

Die Schutzwirkung lässt sich allerdings über den Mechanismus CSP erheblich verbessern, da dieser weit über das Prüfen von Nutzereingaben hinausgeht. Sämtliche in einer Webapplikation geladene Ressourcen wie Bilder, CSS und JavaScript lassen sich dank dieser Technologie steuern.

Die Content Security Policy ist ein Projekt des W3C und greift als Bestandteil des Browsers – es sind keine zusätzlichen Plug-ins oder Ähnliches zu installieren. Für aktuelle Browser gilt CSP Level 3. Auf der entsprechenden Webseite des W3C [2] finden Sie eine vollständige Übersicht aller Versionen einschließlich der unterstützenden Webbrowser.

In Umgebungen, die erhöhte Sicherheitsanforderungen erfordern, beispielsweise Onlinebanking, kann die Browserversion des Clients abgefragt werden und bei erheblich veralteten Varianten des Browsers somit der Zugriff verweigert werden.

Looking for advanced methods to reduce Cybersecurity risks?

4 days of Keynotes, Sessions & Workshops in Munich, December 1 - 5, 2025

Discover now

String userAgent = request.getHeader("user-agent");
String browserName = "";
String  browserVer = "";
if(userAgent.contains("Chrome")){
  String substring=userAgent.substring(userAgent.indexOf("Chrome")).split(" ")[0];
  browserName=substring.split("/")[0];
  browserVer=substring.split("/")[1];
} else if(userAgent.contains("Firefox")) {
  String substring=userAgent.substring(userAgent.indexOf("Firefox")).split(" ")[0];
  browserName=substring.split("/")[0];
  browserVer=substring.split("/")[1];
}

Listing 1 zeigt die Möglichkeit, über den request die Identifikation des Browsers auszulesen. Anschließend demonstrieren die beiden Beispiele, wie die Versionsnummer aus dem Text für Chrome und Firefox extrahiert wird. Bei dieser Strategie sollte man sich aber bewusst sein, dass es für Schwindler recht einfache Möglichkeiten gibt, die Nutzung eines anderen Browsers vorzugaukeln.

Damit wird uns noch einmal vor Augen geführt, dass Web Application Security als ganzheitliches Konzept zu verstehen ist, in dem mehrere Maßnahmen als Verbund wirken – denn einzelne Techniken lassen sich durchaus umgehen. Schauen wir uns daher nun den Wirkmechanismus von CSP im Detail an.

Beginnen wir mit einer reinen HTML-Ausgabe, die CSS, Google Fonts, CDN JavaScript, ein YouTube iFrame und Grafiken enthält. Listing 2 dient uns als Ausgangspunkt, ohne den Einsatz von CSP.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    
    <title>Content Security Policy Demo</title>
    
    <link rel="stylesheet" href="proxy.php?url=style.css" />
    
    <link
      href="proxy.php?url=https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap"
      rel="stylesheet"
    />
    
    <link
      rel="stylesheet"
      href="proxy.php?url=https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css"
      integrity="sha384-TX8t27EcRE3e/ihU7zmQxVncDAy5uIKz4rEkgIXeMed4M0jlfIDPvg6uqKI2xXr2"
      crossorigin="anonymous"
    />
  </head>

  <body>
    <main>
      <div class="box">
        <div id="vue"></div>
      </div>

      <div class="box">
        <div class="embed">
          <iframe width="100%" height="500px" frameborder="0"
            src="proxy.php?url=https://www.youtube.com/embed/3nK6rcAbuzo"
            allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
            allowfullscreen></iframe>
        </div>
      </div>

      <div class="box">
        <div class="grid">
          <img src="proxy.php?url=https://images.unsplash.com/photo-1535089780340-34cc939f9996?ixlib=rb-1.2.1&auto=format&fit=crop&w=500&q=80" />
          <img src="proxy.php?url=https://images.unsplash.com/photo-1587081917197-95be3a2d2103?ixlib=rb-1.2.1&auto=format&fit=crop&w=500&q=80" />
          <img src="proxy.php?url=https://images.unsplash.com/photo-1502248103506-76afc15f5c45?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=500&q=80" />
        </div>
      </div>
    </main>

    <script src="proxy.php?url=https://cdn.jsdelivr.net/npm/[email protected]/dist/vue.min.js"></script>
    <script nonce="rAnd0m">
      new Vue({
        el: '#vue',
        render(createElement) {
          return createElement('h1', 'Hello World!');
        },
      });
    </script>
  </body>
</html>

Wie wir in Abbildung 1 sehen können, handelt es sich hierbei um eine einfache HTML-Seite, die verschiedenen Content lädt. Dazu gehört zum Beispiel auch, das JavaScript-Framework Bootstrap extern über das Content Delivery Network (CDN) jsDelivr zu laden. Wer mit dem Thema CDN noch nicht vertraut ist, findet dazu einen sehr informativen Artikel auf Wikipedia [3]. Stellen wir uns nun einmal ein realistisches Szenario aus der Praxis vor.

Es könnte nun sein, dass die von uns verwendete Bootstrap-Bibliothek eine bekannte Sicherheitslücke für XSS-Angriffe enthält. Der Content des CDN von jsDelivr ist durchaus vertrauenswürdig. Ein Angreifer könnte nun aber versuchen, von einem Webspace eine eigens präparierte JavaScript-Datei über die Bootstrap-Sicherheitslücke einzuschleusen. Ich möchte an dieser Stelle natürlich kein Hackertutorial an die Hand geben und erklären, wie ein solcher Angriff ausgeführt werden kann; ebensowenig möchte ich Ideen verbreiten, welcher Unfug sich über XSS anstellen lässt. Mir geht es darum, eine zuverlässige Methode vorzustellen, die den Angriff wirkungsvoll verhindern kann. Also richten wir unser Augenmerk nun auf die Prävention von XSS.

Schutz durch CSP

Mittels CSP werden nun Meta-Header-Attribute gesetzt, mit denen bestimmt werden kann, was zuverlässige Quellen sind. Das erlaubt es jedem Contenttyp (Ressource, also Bild, CSS und so weiter), explizite, vertrauenswürdige Quellen (Domains) zuzuweisen. Damit lassen sich JavaScript-Dateien so einschränken, dass sie nur vom eigenen Server geladen werden und beispielsweise von CDN jsDelivr. Findet ein Angreifer nun einen Weg, eine XSS-Attacke auszuführen, bei der er versucht, von einer anderen Domain als von den erlaubten Domains Schadcode einzuschleusen, blockiert CSP das Skript von der nicht freigegebenen Domain.

Dazu ein einfaches Beispiel: Wenn wir im <head> in Listing 2 gleich nach dem meta-Tag für die Seitencodierung die Zeile <meta http-equiv=”Content-Security-Policy” content=”default-src ‘self'” /> einfügen und die Datei ausführen, bekommen wir eine Ausgabe wie in Abbildung 2.

Der Teil content=”default-src ‘self'” sorgt dafür, dass sämtliche Inhalte, die nicht von der eigenen Domäne stammen, über CSP im Browser blockiert werden. Wollen wir zusätzlich für JavaScript das jsDelivr CDN zulassen, müssen wir den meta-Tag wie in folgt formulieren:

<meta http-equiv="Content-Security-Policy"
  content="default-src 'self';
  script-src 'nonce-rAnd0m' https://cdn.jsdelivr.net; />

Auf der offiziellen Webseite für Content Security Policy [4] finden Sie eine vollständige Auflistung sämtlicher Attribute und eine umfangreiche Liste an Beispielen. So bewirkt der Ausdruck nonce-rAnd0m dass Inline-Skripte geladen werden dürfen. Dazu muss das zugehörige JavaScript mit dem Attribut <script nonce=”rAnd0m”> gekennzeichnet werden. Damit unser Beispiel aus Listing 2 vollständig funktioniert, benötigen wir für den CSP-meta-Tag folgenden Eintrag (Listing 3).

<meta http-equiv="Content-Security-Policy"
  content="default-src 'self';
  script-src 'nonce-rAnd0m' https://cdn.jsdelivr.net;
  img-src https://images.unsplash.com;
  style-src 'self' https://cdn.jsdelivr.net;
  frame-src https://www.youtube.com;
  font-src https://fonts.googleapis.com;" />

Für Java-Webapplikationen können die Headerinformationen zu den Beschränkungen der CSP über den response hinzugefügt werden. Die Zeile response.addHeader (“Content-Security-Policy”, “default-src ‘self'”); bewirkt wie zu Beginn, dass sämtliche Inhalte, die nicht von der eigene Domäne stammen, blockiert werden.

Zentrale Regelung über Servlet-Filter

Nun ist das applikationsweite manuelle Hinzufügen von CSP-Regeln für jede eigene Seite recht mühselig und zudem noch sehr fehleranfällig. Eine zentrale Lösung für den Einsatz von Java-Servern ist die Verwendung von Servlet-Filtern (Listing 4).

public class CSPFilter implements Filter {

  public static final String POLICY = "default-src 'self'";

  @Override
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
  throws IOException, ServletException {
    if (response instanceof HttpServletResponse) {
      ((HttpServletResponse)response).setHeader("Content-Security-Policy", CSPFilter.POLICY);
    }
  }

  @Override
  public void init(FilterConfig filterConfig) throws ServletException { }

  @Override
  public void destroy() { }
}

Um den Filter dann zum Beispiel im Apache Tomcat zu aktivieren, wird noch ein kleiner Eintrag in der web.xml benötigt (Listing 5).

<filter>
  <filter-name>CSPFilter</filter-name>
  <filter-class>com.content-security-policy.filters.CSPFilter</filter-class>
</filter>
<filter-mapping>
  <filter-name>CSPFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

Sicher könnte man für sämtliche Applikationen in einem vorgeschalteten Proxyserver wie dem Apache-2-HTTP-Server oder NGNIX alle CSP-Regeln zentral verwalten. Davon ist allerdings aus zwei Gründen abzuraten: Zum einen verlagert sich so die Verantwortlichkeit von der Entwicklung hin zum Betrieb, was zu erhöhtem Kommunikationsaufwand und einem Flaschenhals in der Entwicklung führt. Zum anderen werden die so entstehenden Regeln sehr komplex und entsprechend schwieriger zu lesen beziehungsweise zu warten. Der hier vorgeschlagene Servlet-Filter ist daher eine gute Option, um die Sicherheitsregeln applikationsweit zentral für exakt die entwickelte Anwendung zu verwalten. Zudem passt das auch hervorragend in ein agiles DevOps-Konzept, denn die notwendige Konfiguration ist Bestandteil des Source Codes und über die Versionsverwaltung unter Konfigurationsmanagement zugänglich.

Fazit

Wie ich in diesem Artikel zeigen konnte, ist das Thema Web-Application-Security nicht immer gleich ein Fall für Spezialisten. Persönlich empfinde ich es als eine große Errungenschaft der letzten Jahre, wie das Härten von Webanwendungen kontinuierlich einfacher wird. CSP halte ich auf diesem Weg für einen Schritt in die richtige Richtung. Natürlich gilt es weiterhin, stets ein Auge auf aktuelle Entwicklungen zu haben, denn die bösen Buben und Mädels ruhen sich nicht auf ihren Lorbeeren aus und lassen sich ständig neue Gemeinheiten einfallen. Der gerade populär gewordene breite Einsatz von künstlichen neuronalen Netzen wie ChatGPT lässt im Moment nur grob erahnen, was uns künftig noch an Cyberangriffen aus den Tiefen des weltweiten Netzes erwarten wird.

The post Mit Content Security Policy gegen Cross-site Scripting appeared first on IT Security Summit.

Falls ihr keine IT-Sicherheitsexperten seid, solltet ihr daher lieber auf Altbewährtes setzen. Die Sicherheitsarchitektur von Java, genannt Java SE, ist eine gute Wahl [4]. Sie beinhaltet eine große Zahl an Schnittstellen, Tools und Unterstützung für häufig genutzte Sicherheitsalgorithmen, -mechanismen und -protokolle. Mit der Java-Sicherheitsarchitektur könnt ihr folgende Aufgaben realisieren:

• Kryptografie

• Öffentliche Schlüssel generieren

• Sichere Kommunikation

• Authentifizierung

• Zugriffskontrolle

Looking for advanced methods to reduce Cybersecurity risks?

4 days of Keynotes, Sessions & Workshops in Munich, December 1 - 5, 2025

Discover now

Java SE bringt zudem Erweiterungen sowie Dienste mit, die beim Entwickeln einer sicheren Anwendung unterstützen. Hierzu zählen insbesondere:

• JSSE (Java Secure Socket Extension): stellt SSL-bezogene Dienste zur Verfügung

• JCE (Java Cryptography Extension): kryptografische Dienste

• JAAS (Java Authentication and Authorization Service): Dienste, die sich mit Zugangskontrollen und Authentifizierung beschäftigen

Um eine Anwendung auf sicherheitsbezogene Ereignisse hin zu untersuchen, übergebt ihr dem Java-Befehl das folgende Argument:

-Djava.security.debug

Authentifizierung

Derzeit stehen drei Module für die Authentifizierung unter Java zur Verfügung:

• Krb5LoginModule: Authentifizierung mittels Kerberos-Protokoll

• JndiLoginModule: Anmeldung mit Benutzername und Passwort, indem LDAP- oder NIS- Datenbanken zum Einsatz kommen

• KeyStoreLoginModule: Anmeldung am PKCS-#11-Schlüsselspeicher

Falls ihr euch für das geläufige Verfahren mit Benutzername und Passwort entscheidet, um die Anmeldung der Benutzer zu sichern, dann benutzt am besten das JndiLoginModule. Hierbei könnt ihr auf die Klasse LoginContext zurückgreifen, die ihr wie folgt initialisiert [5]:

LoginContext loginContext = new LoginContext("Sample", new SampleCallbackHandler());
loginContext.login();

Wichtig ist, dass ihr dem Log-in-Handler einen Konfigurationsnamen sowie den CallbackHandler übergebt. Der CallbackHandler legt fest, ob die Eingabeaufforderungen für den Benutzernamen und das Kennwort nacheinander erscheinen oder beides in einem einzigen Fenster eingeblendet wird [6]. In der Konfigurationsdatei jaas.conf gebt ihr dann das erforderliche Log-in-Modul ein, mit dem eure Anwendung die Authentifizierung vornimmt. In der Regel lässt sich das Log-in-Modul mit nur wenigen Zeilen konfigurieren:

Sample {
  com.sun.security.auth.module.JndiLoginModule required;
};

Beim Starten der Java-Anwendung sind weitere Argumente erforderlich. So müssen der SecurityManager ex-tra aufgerufen und der Pfad zur Konfigurationsdatei jaas.conf angegeben werden:

java -Djava.security.manager -Djava.security.auth.login.config=/Pfad/zu/jaas.conf

Wem das nicht ausreicht, der kann auf weitere vordefinierte Log-in-Module [7] der Software AG zurückgreifen [8]. Zudem existieren Bibliotheken, die eine Implementierung mit geringerer Komplexität erlauben. So basiert etwa Apache Shiro auf der Java Security, vereinfacht jedoch die Konfiguration sowie Umsetzung von Authentifizierung, Autorisierung, Kryptografie und Benutzermanagement [9].

Zugriffskontrolle

Aber auch mit der Java Security kann eine Autorisierung für Benutzer implementiert werden. Hierbei ist eine Konfigurationsdatei mit der Endung .policy erforderlich, die sich mit policytool aus der JDK-Umgebung erstellen lässt (Abb. 1). Laut der Dokumentation des Java Security API läuft policytool zwar demnächst ab, doch gibt es derzeit keinen guten Ersatz dafür. policytool verfügt über eine grafische Oberfläche und lässt sich durch Eingabe des Befehls policytool auf der Konsole starten. Per Klick auf Policy-Eintrag hinzufügen öffnet sich ein neues Fenster, in dem sich unter anderem eine Berechtigung definieren lässt. Eine neue Berechtigung erzeugt man per Klick auf Berechtigung hinzufügen. Im Fenster Berechtigungen wird zunächst die Art der Berechtigung ausgewählt, in unserem Beispiel handelt es sich dabei um eine FilePermission, also Dateiberechtigung. Sie lässt sich auf eine bestimmte Datei oder auf alle Dateien unter Zielname anwenden. Bei Aktionen können zulässige Dateirechte wie lesen oder schreiben ausgewählt werden. Das Feld signiert von kann leer sein.

Abb. 1: Berechtigungen mit policytool erstellen

Nachdem alle Einstellungen vorgenommen wurden, kann die .policy-Datei mit Datei | Speichern abgespeichert werden:

/* AUTOMATICALLY GENERATED ON Mon Sep 12 18:46:47 CEST 2022*/
/* DO NOT EDIT */
grant {
  permission java.io.FilePermission "<<ALL FILES>>", "read,write";
};

Die konkrete Umsetzung der Zusatzkontrolle mit Java-Bordmitteln lässt sich bewerkstelligen wie in Listing 1 gezeigt. Wichtig ist, dem Java-Befehl beim Starten des Java-Programms folgende Argumente zu übergeben:

-Djava.security.manager -Djava.security.policy=/Pfad/zu/Datei.policy

Um die Ressourcen vom SecurityManager beschützen zu lassen, muss dieser zunächst initialisiert werden. Anschließend könnt ihr mittels der Methode securityManager.checkPermission überprüfen, ob beispielsweise ein Benutzer eine Datei löschen darf.

SecurityManager SecurityManager = System.getSecurityManager();
String path = "files/test.txt";
try {
  if (securityManager != null) {
    securityManager.checkPermission(new FilePermission(path, "delete"));
    System.out.println("it seems as if you're allowed to delete it");
  }
} catch (AccessControlException e) {
  System.out.println("Not allowed to perform this action: "+e.getMessage());
}

Geheimschlüssel

Werden Nachrichten, Benutzeranmeldedaten und weitere sensible Daten unverschlüsselt über das Netzwerk verschickt, haben Hacker leichtes Spiel. Die Kryptografie wird in Java daher sehr ernst genommen. Speziell das Framework Java Cryptography Architecture (JCA) wurde daher in die JDK- beziehungsweise JRE-Umgebung integriert [10]. Das JCA-Framework kann nützlich sein, wenn ihr euch unter anderem mit den folgenden Themen beschäftigen wollt:

• digitale Signaturen

• Message Digests (MD): kryptografische Hashfunktion [11]

• Zertifikate sowie Zertifikatsvalidierung

• Verschlüsselung (symmetrische/asymmetrische Block- und Stromchiffren)

• Generierung sowie Verwaltung von Schlüsseln

• sichere Zufallszahlengenerierung

Verschlüsselungsalgorithmen, die die Vertraulichkeit von Daten schützen, können entweder symmetrischer oder asymmetrischer Natur sein. So handelt es sich bei Geheimschlüsseln (Secret Keys) um symmetrische Algorithmen, da derselbe Schlüssel sowohl zur Verschlüsselung als auch zur Entschlüsselung benutzt wird. Anders verhält es sich bei asymmetrischen Algorithmen, bei denen unterschiedliche Schlüssel für die Verschlüsselung und die Entschlüsselung zum Einsatz kommen [1].

Ein Beispiel für symmetrische Algorithmen stellt der „Data Encryption Standard“ (DES) dar. Obwohl DES bereits in den 1970ern entwickelt und mittlerweile von diversen fortgeschrittenen Standards überholt wurde, ist er immer noch in Gebrauch. DES kommt vor allem im kommerziellen sowie im Finanzsektor zum Einsatz. Die eigentliche Schlüsselgröße von DES beträgt zwar 56 Bit, allerdings hat sich heutzutage vor allem die Option Triple DES mit einer Schlüsselgröße von 3 x 56 Bit durchgesetzt [1].

import java.security.spec.KeySpec;
import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.DESedeKeySpec;
import org.apache.commons.codec.binary.Base64;
 
public class TrippleDes {
 
  private static final String UNICODE_FORMAT = "UTF8";
  public static final String DESEDE_ENCRYPTION_SCHEME = "DESede";
  private KeySpec ks;
  private SecretKeyFactory skf;
  private Cipher cipher;
  byte[] arrayBytes;
  private String myEncryptionKey;
  private String myEncryptionScheme;
  SecretKey key;
 
  public TrippleDes(String sKey) throws Exception {
    myEncryptionKey = sKey;
    myEncryptionScheme = DESEDE_ENCRYPTION_SCHEME;
    arrayBytes = myEncryptionKey.getBytes(UNICODE_FORMAT);
    ks = new DESedeKeySpec(arrayBytes);
    skf = SecretKeyFactory.getInstance(myEncryptionScheme);
    cipher = Cipher.getInstance(myEncryptionScheme);
    key = skf.generateSecret(ks);
  }
  public String encrypt(String unencryptedString) {
    String encryptedString = null;
    try {
      cipher.init(Cipher.ENCRYPT_MODE, key);
      byte[] plainText = unencryptedString.getBytes(UNICODE_FORMAT);
      byte[] encryptedText = cipher.doFinal(plainText);
      encryptedString = new String(Base64.encodeBase64(encryptedText));
    } catch (Exception e) {
      e.printStackTrace();
    }
    return encryptedString;
  }
 
  public String decrypt(String encryptedString) {
    String decryptedText=null;
    try {
      cipher.init(Cipher.DECRYPT_MODE, key);
      byte[] encryptedText = Base64.decodeBase64(encryptedString);
      byte[] plainText = cipher.doFinal(encryptedText);
      decryptedText= new String(plainText);
    } catch (Exception e) {
      e.printStackTrace();
    }
    return decryptedText;
  }
}

Unter Java könnt ihr Triple DES implementieren wie in Listing 2 dargestellt [12]. Triple DES wird im Konstruktor eingerichtet, dem der Geheimschlüssel als Argument im Klartext übergeben wird. Im weiteren Verlauf der Einrichtung kommt die SecretKeyFactory zum Einsatz, um die Byterepräsentation des Geheimschlüssels in ein SecretKey-Objekt umzuwandeln. Anhand der Implementierung der encrypt– und decrypt-Methoden lässt sich gut erkennen, dass die Entschlüsselung eine Umkehrfunktion der Verschlüsselung ist. Anschließend könnt ihr einen String wie folgt ver- und entschlüsseln:

TrippleDes triple = new TrippleDes("Caesarsalad!Caesarsalad!");
String encPw = triple.encrypt("password123");
String decPw = triple.decrypt(encPw);

Abhörsichere Leitung

Vertrauliche Kommunikation über einen Kanal wie das öffentliche Internet erfordert die Verschlüsselung von Daten. Aus diesem Grund ist es absolut notwendig, das Verschlüsselungsprotokoll Transport Layer Security (TLS), ehemals bekannt als Secure Socket Layer (SSL), einzusetzen. Andernfalls könnte ein Hacker in Versuchung geraten, einen Packet Sniffer einzusetzen, der den Netzwerkverkehr analysiert. Beispielsweise lassen sich sensible Daten wie Kreditkartennummern vor dem Versand unverschlüsselt speichern. Die einfachste Lösung, um weder den Server noch den Client mit einem zu Fehlern neigenden Verschlüsselungscode zu überladen, besteht darin, Secure Sockets einzusetzen.

Als Beispiel soll eine verschlüsselte Kommunikation zwischen Server und Client dienen [13]. Beide verwenden einen Secure Socket, wobei die Daten in Form von JSON-Daten gesendet und empfangen werden. Wie sich der Server, bestehend aus einem Secure Socket, realisieren lässt, zeigt Listing 3. Falls der Server Teil einer Client-/Server-Anwendung ist, sollte er die Thread-Klasse erweitern. Dadurch wird die Anwendung multitaskingfähig. So kann der Server parallel mit den angeschlossenen Clients kommunizieren, während er weitere Aufgaben erledigt.

import java.io.*;
import java.net.*;
import java.security.KeyManagementException;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.UnrecoverableKeyException;
import java.security.cert.CertificateException;
import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicBoolean;
import javax.net.*;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLServerSocket;
import javax.net.ssl.SSLServerSocketFactory;
 
public class ServerConnection extends Thread {
  private final int port;
  private AtomicBoolean running = new AtomicBoolean(false);
  private ExecutorService pool;
 
  public ServerConnection(int p) {
    this.port = p;
    pool = Executors.newFixedThreadPool(10000);
  }
 
  public void run() {
    running.set(true);
    this.setupSecureSocket();
  }
 
  public void setupSecureSocket() {
    try {
      ServerSocketFactory factory = ServerSocketFactory.getDefault();
      ServerSocket socket = factory.createServerSocket(port);
      System.out.println("creating server socket");
      while (running.get()) {
        try {
          Socket s = socket.accept();
          Runnable r = new ServerThread(s);
          pool.submit(r);
          
        } catch (IOException ex) {
          System.out.println("Exception accepting connection");
        } catch (RuntimeException ex) {
          System.out.println("Unexpected error"+ex.getMessage());
        }
      }
      System.out.println("shutting down server");
      pool.shutdown();
      socket.close();
      
    } catch (BindException ex) {
      System.out.println("Could not start server. "+ex.getMessage());
    } catch (IOException ex) {
      System.out.println("Error opening server socket: "+ex.getMessage());
    }
  }
  
  public void interrupt() {
    running.set(false);
  }
  
  private boolean isRunning() {
    return running.get();
  }
}

In Listing 3 wird der Server initialisiert, indem die Portnummer als Argument übergeben wird. Außerdem wird mittels des ExecutorService-Objekts die Zahl der Threads festgelegt, die der Server verarbeiten kann. So können in diesem Beispiel bis zu 10 000 Clients mit dem Server verbunden werden.

Da die Klasse ServerConnection von der Thread-Klasse die Methoden und Attribute erbt, ist es zusätzlich erforderlich, die bekannte run-Methode zu überschreiben. In diesem Fall reicht es aus, die selbst definierte Methode setupSecureSocket() aufzurufen. Dort wird zunächst der Secure Socket des Servers initialisiert, was dazu führt, dass der Server auf einem sicheren Kanal mit der Portnummer XY lauscht. Solange die Variable running vom Typ AtomicBoolean den Wert true aufweist, kann der Server neue Clients zulassen, indem jeder Client als ein Runnable-Objekt zum Pool hinzugefügt wird. Die Klasse ServerConnection stellt weitere Hilfsmethoden zur Verfügung, mit denen sich der Server steuern lässt. So kann mittels Aufruf der Methode interrupt() jederzeit das Verwalten der Clients unterbrochen werden. Der Aufruf der Methode isRunning() zeigt an, ob der Server noch läuft.

Bei der Anmeldung am Server wird jedem Client ein ServerThread-Objekt vom Typ Runnable zugeordnet (Listing 4). Die Implementierung der Runnable-Schnittstelle sorgt dafür, dass die run-Methode nicht mehr explizit aufgerufen werden muss. Zusätzlich wird beim Anlegen des ServerThread-Objekts der Socket des Clients übergeben, um damit den BufferedWriter sowie InputStreamReader zu initialisieren.

Der Aufruf von start() erfolgt in der überschriebenen run-Methode und sorgt dafür, dass der booleschen Variable shutdown der Wert false zugewiesen wird. Durch den anschließenden Aufruf von getIncomingData() wird der InputStreamReader gestartet, sodass in der while-Schleife konstant Nachrichten vom Client empfangen und zu einem JSON-Objekt geparst werden. Daneben beinhaltet die ServerThread-Klasse die Methode disconnect(), die die Verbindung zum Client kappt. Hierbei wird die boolesche Variable shutdown auf true gesetzt, was dazu führt, dass die while-Schleife unterbrochen wird.

import org.json.simple.JSONObject;
import org.json.simple.parser.JSONParser;
import org.json.simple.parser.ParseException;
import java.net.Socket;
import java.io.Writer;
import java.io.BufferedWriter;
import java.io.OutputStreamWriter;
import java.io.InputStreamReader;
import java.io.IOException;
import java.io.BufferedInputStream;
import java.io.Reader;
import java.io.BufferedReader;
 
public class ServerThread implements Runnable {
  private final Socket connection;
  private Writer out;
  private Reader in;
  private BufferedReader reader;
  private volatile boolean shutdown;
 
  public ServerThread(Socket s) {
    this.connection = s;
    
  }
 
  public void run() {
  
    try {
      this.out = new BufferedWriter(new OutputStreamWriter(connection.getOutputStream(), "US-ASCII"));
      
      System.out.println("client address: " + this.connection.getRemoteSocketAddress());
      {
        this.start();
        getIncomingData();
      } catch(IOException ex) {
        System.out.println("Error talking to " + this.connection.getRemoteSocketAddress()+" "+ex.getMessage());
      }
    }
    
    private void getIncomingData() {
      JSONParser parser = new JSONParser();
      
      try {
        this.in = new InputStreamReader(new BufferedInputStream(connection.getInputStream()));
        this.reader = new BufferedReader( this.in);
        String line = "";
        while(!shutdown){
          if ((line =  this.reader.readLine()) != null) {
            System.out.println("line: "+line);
            JSONObject json = (JSONObject) parser.parse(line);
            System.out.println("reading in json "+json);
          } else {
            this.in.close();
            disconnect();
          }
        }
        
      } catch(IOException ex) {
        System.out.println("could not read in data: " + ex.getMessage());
      } catch(ParseException ex) {
        System.out.println("could not parse JSONObject: " + ex.getMessage());
      }
    }
    
    public void disconnect() {
      try {
        this.connection.close();
        shutdown();
        System.out.println("closing client socket ");
      } catch (IOException ex) {
        System.out.println("could not close client socket " + ex.getMessage());
      }
    }
    
    public void shutdown() {
      shutdown = true;
    }
    
    public void start() {
      shutdown = false;
    }
  }
}

Auch beim Client muss ein Secure Socket erstellt werden, um darüber eine Verbindung zum Server aufzubauen. Die Umsetzung des Clients erfolgt durch die Klasse ClientConnection (Listing 5). So werden beim Erstellen des ClientConnection-Objekts sowohl die Portnummer als auch der Hostname des Servers als Argumente übergeben.

Das Herzstück der ClientConnection ist die connect-Methode, da dort der Secure Socket mittels SSLSocketFactory eingerichtet wird. Zudem werden dort sowohl der BufferedWriter, der zum Schreiben von Daten an den Server gebraucht wird, als auch der InputStream, über den Daten vom Server empfangen werden, initialisiert. Erwähnenswert ist in diesem Zusammenhang die Methode disconnect(), welche die Verbindung zum Server beendet. Durch den Aufruf von write() können Stringnachrichten an den Server verschickt werden.

import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.io.Writer;
import java.net.Socket;
import java.util.concurrent.atomic.AtomicBoolean;
import javax.net.SocketFactory;
import javax.net.ssl.SSLSocketFactory;
 
public class ClientConnection implements Runnable {
  private Socket socket;
  private OutputStream out;
  private Writer writer;
  private InputStream in;
  private String host = "";
  private int port = 0;
  private AtomicBoolean running = new AtomicBoolean(false);
 
  public ClientConnection(String host, int p) {
    this.host = host;
    this.port = p;
  }
  
  public void run() {
    read();
  }
 
  public void connect() {
    try {
      SocketFactory factory = SSLSocketFactory.getDefault();
      this.socket = factory.createSocket(host, port);
      this.socket.setSoTimeout(100000);
      this.out = this.socket.getOutputStream();
      this.writer = new BufferedWriter(new OutputStreamWriter(this.out, "UTF-8"));
      this.in = this.socket.getInputStream();
      System.out.println("Could establish connection to server.");
    } catch (IOException ex) {
      System.out.println("Could not connect to server."+ex.getMessage());
    }
  }
  
  public void write(String msg) {
    try {
      if(this.writer != null) {
      this.writer.write(msg);
      this.writer.flush();
    } else {
      System.out.println("Could not write to server.");
    }
  } catch (IOException ex) {
    System.out.println("Could not write to server. "+ex.getMessage());
  }
}
 
public void disconnect() {
  if (this.socket != null) {
    try {
      this.socket.close();
      System.out.println("disconnected from server");
    } catch (IOException ex) {
      System.out.println("could not disconnect.");
    }
  }
}
 
public boolean isConnected() {
  if ( this.socket != null ) {
    System.out.println("connected to server");
    return true;
  } else {
    System.out.println("not connected to server");
    return false;
  }
}
 
public void read() {
  //TODO: read in from server
  }
}

Die hier vorgestellte Client-/Serveranwendung kann anschließend in der Main-Methode aufgerufen werden. Den Server initialisiert ihr dabei unter Angabe der Portnummer wie folgt:

ServerConnection server = new ServerConnection(9200);
server.run();

Genauso wird der Client gestartet, außer das hier noch ein kleiner Test stattfindet. So versendet der Client persönliche Daten als JSON-String (Listing 6).

ClientConnection client = new ClientConnection("127.0.0.1", 9200);
client.connect();
 
JSONObject jObj = new JSONObject();
jObj.put("Name", "Max Mustermann");
jObj.put("Product-ID", "67x-89");
jObj.put("Address", "1280 Deniston Blvd, NY NY 10083");
jObj.put("Card Number", "4000-1234-5678-9017");
jObj.put("Expires", "10/29");
try {
  TimeUnit.SECONDS.sleep(30);
} catch (InterruptedException e) {
  e.printStackTrace();
}
client.writeToServer(jObj.toJSONString()+"\n");

Trotz des einfach gehaltenen Codes werden die vertraulichen Daten verschlüsselt an den Server gesendet. Überprüfen könnt ihr das unter Linux mit dem Kommandozeilentool Tcpflow [14]. Denn Tcpflow ist eine Art Packet Sniffer, der den gesamten oder auch einen Teil des TCP-Verkehrs aufzeichnet und in eine einfache Datei schreibt. Um beispielsweise den Port mittels Tcpflow abzuhören, der für dieses Beispielprogramm benutzt wird, verwendet ihr folgenden Befehl:

tcpflow -i any port 9200

Beim Aufruf von Tcpflow werden ein oder mehrere Dateien angelegt, welche die Daten beinhalten, die zwischen Client und Server gesendet worden sind. Dabei ähneln die Dateinamen dem folgenden Beispiel:

127.000.000.001.38226-127.000.000.001.09200

Unschwer zu erkennen ist, dass Daten vom Client mit der Portnummer 38226 an den Server mit der Portnummer 9200 gesendet worden sind. Schaut ihr euch allerdings den aufgezeichneten Netzwerkverkehr im Texteditor an, so werdet ihr abgesehen von kryptischen Symbolen keinerlei persönliche Daten entdecken (Abb. 2). Allerdings kann auch der implementierte Server mit den verschlüsselten Daten nichts anfangen, was daran liegt, dass der Server nicht weiß, welches Verschlüsselungsverfahren zum Einsatz kommt.

Abb. 2: Aufzeichnung verschlüsselter Daten

Zertifikatehandel

Der Server aus Listing 3 hat zwar den Vorteil, dass er relativ unkompliziert umsetzbar ist, allerdings unterstützt die factory, die von ServerSocketFactory.getDefault() zurückgegeben wird, lediglich die Authentifizierung [15]. Um die Verschlüsselung serverseitig zu implementieren, sind mehr Codezeilen nötig, was die Implementierung des Servers komplexer macht.

Zunächst legt ihr einen Keystore, einen Truststore sowie ein Zertifikat für den Server an. Genauso geht ihr beim Client vor, was allerdings nicht erforderlich ist, falls der Client allen Zertifikaten des Servers vertraut. Unter Linux stehen euch für solche Zwecke die Kommandozeilentools keytool sowie openssl zur Verfügung [16]:

1. privaten RSA-Schlüssel generieren: $ openssl genrsa -out diagserverCA.key 2048

2. x509-Zertifikat erstellen: $ openssl req -x509 -new -nodes -key diagserverCA.key -sha256 -days 1024 -out diagserverCA.pem

3. PKCS12 Keystore anhand des zuvor generierten Privatschlüssels und Zertifikats erzeugen: $ openssl pkcs12 -export -name server-cert -in diagserverCA.pem -inkey diagserverCA.key -out serverkeystore.p12

4. PKCS12-Keystore in einen Keystore vom Format JKS konvertieren: $ keytool -importkeystore -destkeystore server.keystore -srckeystore serverkeystore.p12 -srcstoretype pkcs12 -alias server-cert

5. falls der Client mit Zertifikaten arbeitet, das Clientzertifikat zum Truststore des Servers hinzufügen: $ keytool -import -alias client-cert -file ../client/diagclientCA.pem -keystore server.truststore

6. Serverzertifikat zum Truststore des Servers hinzufügen: keytool -import -alias server-cert -file diagserverCA.pem -keystore server.truststore

Anschließend ist es erforderlich, die Methode setup-SecureSocket() aus Listing 3 durch den Code aus Listing 7 zu ersetzen. Dabei definiert ihr zunächst den SSLContext (siehe setupSSLContext()), indem ihr eine TrustManagerFactory erstellt. Allerdings kann die TrustManagerFactory dem Wert 0 entsprechen, sofern eine KeyManagerFactory unter Angabe des Schlüsseltyps erzeugt wird. Dann erzeugt ihr ein KeyStore-Objekt vom Typ „JKS“ und befüllt es mit dem Server-Keystore, den ihr zuvor mit keytool erzeugt habt. Zusätzlich initialisiert ihr die KeyManagerFactory unter Angabe des Keystores und des dazugehörigen Passworts. Zu guter Letzt initialisiert ihr den SSLContext, indem ihr den Key-Manager vom Typ KeyManagerFactory, den Trust-Manager vom Typ TrustManagerFactory sowie eine sichere Zufallszahl, die SecureRandomNumber, dem SSLContext als Argumente übergebt. Die letzten beiden Argumente können null sein, falls die Standardeinstellungen ausreichen.

Zusätzlich braucht der Server einen Secure-Server-Socket, um darüber mit den Clients zu kommunizieren. Hierfür kommt eine SSLServerSocketFactory zum Einsatz, womit sich unter Angabe der Portnummer ein SSLServerSocket-Objekt erstellen lässt (siehe setupSSLSocket()). Außerdem lässt sich der Server-Socket weiter einrichten. So brauchen sich Clients nicht zu authentifizieren (vgl. setNeedClientAuth()).

Die letzte Konfiguration betrifft die Verschlüsselungsalgorithmen, die der Server unterstützt. In der Methode setupCipher() werden zunächst die von der aktuellen Java-Umgebung unterstützten Verschlüsselungssuiten geladen. Danach wird durch all diese Verschlüsselungssuiten iteriert, indem nur jene ausgewählt werden, die anonyme und unbestätigte Verbindungen zum SSLServerSocket zulassen. Das ist dann der Fall, wenn im Namen der Suite der String anon vorkommt. Das neue Array wird anschließend der Methode setEnabled-CipherSuites() übergeben.

(..)
private static final String SERVER_KEYSTORE = "server/server.keystore";
(..)
 
public void setupSSLSocket() {
  SSLContext context = setupSSLContext();
  try {
    SSLServerSocketFactory factory = context.getServerSocketFactory();
    SSLServerSocket socket = (SSLServerSocket) factory.createServerSocket(port);
    socket.setNeedClientAuth(false);
    socket.setWantClientAuth(false);
    setupCipher(socket);
    System.out.println("creating server socket");
    while (running.get()) {
      try {
        Socket s = socket.accept();
        Runnable r = new ServerThread(s);
        pool.submit(r);
      } catch (IOException ex) {
        System.out.println("Exception accepting connection");
      } catch (RuntimeException ex) {
        System.out.println("Unexpected error"+ex.getMessage());
      }
    }
    System.out.println("shutting down server");
    pool.shutdown();
    socket.close();
  } catch (BindException ex) {
    System.out.println("Could not start server. "+ex.getMessage());
  } catch (IOException ex) {
    System.out.println("Error opening server socket: "+ex.getMessage());
  }
}
 
public SSLContext setupSSLContext() {
  SSLContext context = null;
  try {
    context = SSLContext.getInstance(“SSL”);
    KeyManagerFactory kmf =KeyManagerFactory.getInstance("SunX509");
    KeyStore ks = KeyStore.getInstance("JKS");
    char [] pw = "boguspw".toCharArray();
    ks.load( new FileInputStream(SERVER_KEYSTORE), pw);
    kmf.init(ks, pw);
    context.init(kmf.getKeyManagers(), null, null);
  } catch (NoSuchAlgorithmException e) {
    System.out.println("wrong algorithm: "+e.getMessage());
    e.printStackTrace();
  } catch (KeyStoreException e) {
    System.out.println("wrong keystore algo: "+e.getMessage());
    e.printStackTrace();
  } catch (CertificateException e) {
    System.out.println("certificate invalid: "+e.getMessage());
    e.printStackTrace();
  } catch (UnrecoverableKeyException e) {
    System.out.println("wrong password for keystore: "+e.getMessage());
    e.printStackTrace();
  } catch (KeyManagementException e) {
    System.out.println("could not initialize context: "+e.getMessage());
    e.printStackTrace();
  } catch (FileNotFoundException e) {
    System.out.println("file not found: "+e.getMessage());
    e.printStackTrace();
  } catch (IOException e) {
    e.printStackTrace();
  }
  return context;
}
 
// anonyme Verschlüsselungssuiten hinzufügen
  public void setupCipher(SSLServerSocket socket) {
    String [] supported = socket.getSupportedCipherSuites();
    String [] anonCipherSuitesSupported = new String [supported.length];
    int numAnonCipherSuitesSupported = 0;
    for (int i = 0; i < supported.length; i++) {
      if(supported[i].indexOf("_anon_") > 0 ) {
        anonCipherSuitesSupported[numAnonCipherSuitesSupported++] = supported[i];
      }
    }
    String [] oldEnabled = socket.getEnabledCipherSuites();
    String [] newEnabled = new String[oldEnabled.length + numAnonCipherSuitesSupported];
    System.arraycopy(oldEnabled, 0, newEnabled, 0, oldEnabled.length);
    System.arraycopy(anonCipherSuitesSupported, 0, newEnabled, oldEnabled.length, numAnonCipherSuitesSupported);
    socket.setEnabledCipherSuites(newEnabled);
  }
(...)

Darüber hinaus braucht der Client einen Socket, der mit dem SSLServerSocket kompatibel ist. In der connect-Methode der Klasse ClientConnection (siehe Listing 5) ersetzt ihr zunächst den Client-Socket durch die folgenden Zeilen:

SSLContext context = setupSSLContext();
SSLSocketFactory socketFactory = context.getSocketFactory();
SSLSocket socket = (SSLSocket) socketFactory.createSocket(host, port);

Außerdem stellt ihr beim Client ein, welche Zertifikate akzeptiert werden. So erlaubt die selbstdefinierte Methode setupSSLContext() alle eingehenden Zertifikate (Listing 8) [17].

// alle Zertifikate akzeptieren
public SSLContext setupSSLContext() {
  SSLContext sc = null;
  TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
      // TODO Auto-generated method stub
    }
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
      // TODO Auto-generated method stub
    }
 
    public X509Certificate[] getAcceptedIssuers() {
      // TODO Auto-generated method stub
      return null;
    }
} };
 
// Trust-Manager installieren
try {
  sc = SSLContext.getInstance("SSL");
  sc.init(null, trustAllCerts, new java.security.SecureRandom());
} catch (NoSuchAlgorithmException e) {
  e.printStackTrace();
} catch (KeyManagementException e) {
  e.printStackTrace();
}
return sc;

Dank der eingerichteten Verschlüsselung kann der Server die verschlüsselte Kreditkarteninformation entschlüsseln und weiterverarbeiten (Abb. 3).

Abb. 3: Ausgabe von verschlüsselten Daten in lesbarer Form

XML-Signaturen

Daten, die in XML-Dateien exportiert und über das Internet versendet werden, sind ebenfalls von Missbrauch bedroht. Um ihre Integrität zu gewährleisten, könnt ihr den Empfehlungen des W3C folgen. Denn XML-Signaturen eignen sich zur Sicherung von Daten jeglicher Art. Hierfür stellt das Java API das Paket java.xml.crypto zur Verfügung. Damit unterstützt es die Erzeugung und Validierung von XML-Signaturen gemäß den empfohlenen Richtlinien.

In der Praxis lässt sich ein XML-Dokument wie in Listing 9 implementieren [18]. Hierbei wird der Klasse MySignature sowohl der Pfad des unsignierten als auch der des neuen XML-Dokuments übergeben. Die selbstdefinierte Methode createSignature() signiert das XML-Dokument in drei Schritten [19]:

7. Schlüsselpaar bestehend aus privatem und öffentlichem Schlüssel generieren

8. XML-Dokument importieren (siehe MySignature.importXML())

9. Original-XML-Dokument mittels des Schlüsselpaars signieren und ein weiteres XML-Dokument zusammen mit der digitalen Signatur erzeugen

Mittels der Klasse aus Listing 9 lässt sich ein bestehendes XML-Dokument wie folgt signieren:

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.security.InvalidAlgorithmParameterException;
import java.security.KeyException;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.NoSuchAlgorithmException;
import java.util.Collections;
import java.util.Iterator;
 
import javax.xml.crypto.MarshalException;
import javax.xml.crypto.dsig.CanonicalizationMethod;
import javax.xml.crypto.dsig.DigestMethod;
import javax.xml.crypto.dsig.Reference;
import javax.xml.crypto.dsig.SignatureMethod;
import javax.xml.crypto.dsig.SignedInfo;
import javax.xml.crypto.dsig.Transform;
import javax.xml.crypto.dsig.XMLSignature;
import javax.xml.crypto.dsig.XMLSignatureException;
import javax.xml.crypto.dsig.XMLSignatureFactory;
import javax.xml.crypto.dsig.dom.DOMSignContext;
import javax.xml.crypto.dsig.dom.DOMValidateContext;
import javax.xml.crypto.dsig.keyinfo.KeyInfo;
import javax.xml.crypto.dsig.keyinfo.KeyInfoFactory;
import javax.xml.crypto.dsig.keyinfo.KeyValue;
import javax.xml.crypto.dsig.spec.C14NMethodParameterSpec;
import javax.xml.crypto.dsig.spec.TransformParameterSpec;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerConfigurationException;
import javax.xml.transform.TransformerException;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
 
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;
import org.xml.sax.SAXException;
 
public class MySignature {
  private String path = "";
  private String output = "";
  public MySignature(String p,String dest) {
    this.path = p;
    this.output = dest;
  }
  public void createSignature() {
    XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");
    try {
      Reference ref = fac.newReference("", fac.newDigestMethod(DigestMethod.SHA384, null), Collections.singletonList (fac.newTransform (Transform.ENVELOPED, (TransformParameterSpec) null)),null, null);
      // SignedInfo-Element erstellen
      SignedInfo si = fac.newSignedInfo(fac.newCanonicalizationMethod(Canoni-calizationMethod.INCLUSIVE, (C14NMethodParameterSpec) null), fac.newSignatureMethod(SignatureMethod.RSA_SHA384, null), Collections.singletonList(ref));
        KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
        kpg.initialize(2048);
        KeyPair kp = kpg.generateKeyPair();
        // KeyValue mit DSA-PublicKey erstellen
        KeyInfoFactory kif = fac.getKeyInfoFactory();
        KeyValue kv = kif.newKeyValue(kp.getPublic());
        KeyInfo ki = kif.newKeyInfo(Collections.singletonList(kv));
        // XML-Dokument importieren
        Document doc = importXML(path);
        // DOMSignContext erstellen und den DSA-PrivateKey
        // sowie den Ort des Eltern-Elements angeben
        DOMSignContext dsc = new DOMSignContext(kp.getPrivate(), doc.getDocumentElement());
        // XMLSignatur-Objekt anlegen
        XMLSignature signature = fac.newXMLSignature(si, ki);
        // Kuvertierte Signatur zusammenstellen und generieren
        signature.sign(dsc);
        // neues Dokument abspeichern
        OutputStream os = new FileOutputStream(this.output);
        TransformerFactory tf = TransformerFactory.newInstance();
        Transformer trans = tf.newTransformer();
        trans.transform(new DOMSource(doc), new StreamResult(os));
    } catch (..)
    // TODO: Ausnahmen hinzufügen
  }
}
// XML-Signatur überprüfen
public boolean isXmlDigitalSignatureValid() throws Exception {
  boolean validFlag = false;
  Document doc = importXML(this.output);
  NodeList nl = doc.getElementsByTagNameNS(XMLSignature.XMLNS, "Signature");
  if (nl.getLength() == 0) {  
    throw new Exception("No XML Digital Signature Found, document is discarded");  
    }
    // DOMValidateContext-Objekt anlegen und einen KeyValue-KeySelector
    // sowie Kontext des Dokuments angeben
    DOMValidateContext valContext = new DOMValidateContext(new KeyValueKeySelector(), nl.item(0));  
    XMLSignatureFactory fac = XMLSignatureFactory.getInstance("DOM");  
    XMLSignature signature = fac.unmarshalXMLSignature(valContext);  
    validFlag = signature.validate(valContext);  
    if (validFlag == false) {
      System.err.println("Signature failed core validation");
      boolean sv = signature.getSignatureValue().validate(valContext);
      System.out.println("signature validation status: " + sv);
      // den Validierungsstatus jeder Referenz prüfen
      Iterator i = signature.getSignedInfo().getReferences().iterator();
      for (int j=0; i.hasNext(); j++) {
        boolean refValid = ((Reference) i.next()).validate(valContext);
        System.out.println("ref["+j+"] validity status: " + refValid);
      }
    } else {
      System.out.println("Signature passed core validation");
    }
    
    return validFlag;
    }
 
    // XML-Dokument importieren
    public Document importXML(String sPath) {
      DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
      dbf.setNamespaceAware(true);
      Document doc = null;
      try {
        doc = dbf.newDocumentBuilder().parse(new FileInputStream(sPath));
      } catch (SAXException | IOException | ParserConfigurationException e) {
      e.printStackTrace();
    }
    return doc;
  }
}

String path = "files/music-jaxb-en.xml";
String signedXML = "files/envelopedSignature.xml";
MySignature xmlSecurity = new MySignature(path,signedXML);
xmlSecurity.createSignature();

Abbildung 4 zeigt das signierte XML-Dokument, bei dem die digitale Signatur innerhalb des Wurzeltags eingefügt wird. Der hierfür verwendete Algorithmus, genannt RSA-SHA384, orientiert sich dabei an den Vorgaben von W3C.

Abb. 4: Signiertes XML-Dokument

Darüber hinaus lässt sich die Signatur des XML-Dokuments auf Richtigkeit hin validieren. Die selbst definierte Methode aus Listing 9, genannt isXmlDigitalSignatureValid(), lädt zunächst den Inhalt des Signature-Tags und übergibt diesen zusammen mit dem KeyValueKeySelector-Objekt (Listing 10) dem DOMValidateContext. Dann werden die eingelesenen XML-Knoten in Objekte umgewandelt und als XMLSignature-Objekt gespeichert. Das XMLSignature-Objekt bekommt anschließend das zuvor erstellte DOMValidateContext-Objekt übergeben. Die validate-Methode gibt true zurück, falls die Signatur laut den Regeln des W3C erfolgreich validiert worden ist; ansonsten gibt sie false zurück.

In Listing 10 ist der KeySelector definiert, der den öffentlichen Schlüssel aus dem KeyValue-Element abruft und ihn zurückgibt. Wenn der Schlüsselalgorithmus nicht mit dem Signaturalgorithmus übereinstimmt, wird der öffentliche Schlüssel ignoriert.

import java.security.KeyException;
import java.security.PublicKey;
import java.util.List;
import javax.xml.crypto.AlgorithmMethod;
import javax.xml.crypto.KeySelector;
import javax.xml.crypto.KeySelectorException;
import javax.xml.crypto.KeySelectorResult;
import javax.xml.crypto.XMLCryptoContext;
import javax.xml.crypto.XMLStructure;
import javax.xml.crypto.dsig.SignatureMethod;
import javax.xml.crypto.dsig.keyinfo.KeyInfo;
import javax.xml.crypto.dsig.keyinfo.KeyValue;
 
public class KeyValueKeySelector extends KeySelector {
 
  public KeySelectorResult select(KeyInfo keyInfo,KeySelector.Purpose purpose,AlgorithmMethod method,XMLCryptoContext context)throws KeySelectorException {
 
    if (keyInfo == null) {
      throw new KeySelectorException("Null KeyInfo object!");
    }
    SignatureMethod sm = (SignatureMethod) method;
    List list = keyInfo.getContent();
 
    for (int i = 0; i < list.size(); i++) {
      XMLStructure xmlStructure = (XMLStructure) list.get(i);
      if (xmlStructure instanceof KeyValue) {
        PublicKey pk = null;
        try {
          pk = ((KeyValue)xmlStructure).getPublicKey();
        } catch (KeyException ke) {
          throw new KeySelectorException(ke);
        }
        // prüfen, ob der Algorithmus kompatibel mit der Methode ist
        if (algEquals(sm.getAlgorithm(), pk.getAlgorithm())) {
          return new SimpleKeySelectorResult(pk);
        }
      }
    }
    throw new KeySelectorException("No KeyValue element found!");
  }
 
  private static boolean algEquals(String algURI, String algName) {
    if (algName.equalsIgnoreCase("DSA") && algURI.equalsIgnoreCase("http://www.w3.org/2009/xmldsig11#dsa-sha256")) {
      return true;
    } else if (algName.equalsIgnoreCase("RSA") && algURI.equalsIgnoreCase("http://www.w3.org/2001/04/xmldsig-more#rsa-sha384")) {
      return true;
    } else {
      return false;
    }
  }
}

Das in Listing 10 angelegte KeyValueKeySelector-Objekt wird benötigt, um Schlüssel für die Validierung der digitalen Signatur zu finden. Alternativ kann direkt ein öffentlicher Schlüssel angegeben werden. Allerdings ist es oft nicht vorhersehbar, welcher Schlüssel passt.

Der KeyValueKeySelector (Listing 10) leitet die abstrakte Klasse KeySelector ab. Er versucht, einen angemessenen öffentlichen Schlüssel zu ermitteln, indem er auf Daten der KeyValue-Elemente aus dem KeyInfo-Tag eines XMLSignature-Objekts zurückgreift. Diese Implementierung überprüft nicht, ob der Schlüssel verlässlich ist. Sobald der KeyValueKeySelector einen geeigneten öffentlichen Schlüssel findet, wird dieser über das SimpleKeySelectorResult-Objekt zurückgegeben (Listing 11).

import java.security.Key;
import java.security.PublicKey;
 
import javax.xml.crypto.KeySelectorResult;
 
public class SimpleKeySelectorResult implements KeySelectorResult {
  private PublicKey pk;
  
  public SimpleKeySelectorResult(PublicKey pk) {
    this.pk = pk;
  }
  
  public Key getKey() {
    return pk;
  }
  
}

In Listing 12 könnt ihr sehen, wie sich die selbst definierte Klasse MySignature initialisieren und ausführen lässt.

String path = "files/music-jaxb-en.xml";
String signedXML = "files/envelopedSignature.xml";
MySignature xmlSecurity = new MySignature(path,signedXML);
xmlSecurity.createSignature();
try {
  xmlSecurity.isXmlDigitalSignatureValid();
} catch (Exception e) {
  e.printStackTrace();
}

The post Java-Anwendungen mit Bordmitteln absichern appeared first on IT Security Summit.

Eine gute Übersicht über die am häufigsten auftretenden Sicherheitsprobleme geben die OWASP Top 10 [1]. Diese Schwachstellen möglichst früh im Entwicklungsprozess zu erkennen, bringt einige Vorteile:

1. Wenn mögliche Schwachstellen direkt im Entwicklungszyklus angezeigt werden, lernen die Entwickler:innen, diese in Zukunft direkt zu vermeiden. Das macht das System sicherer und spart Geld, weil weniger Fehler beseitigt werden müssen.

2. Selten durchgeführte, aufwendige Penetrationstests passen nicht zu agilen Vorgehensmodellen mit kurzen Auslieferungszyklen. Wenn man sich allein auf Penetrationstests verlässt, können in dazwischenliegenden Releases Schwachstellen in Produktion gebracht werden, die Angriffspunkte für mögliche Attacken sein können.

Schwachstellen können mit jedem Commit ins System kommen. Auch kann sich die Gefahrenlage mit der Zeit ändern, z. B. wenn neue Schwachstellen in genutzten Bibliotheken öffentlich bekannt werden. Deshalb ist es wichtig, Schwachstellenmanagement als einen kontinuierlichen Prozess aufzusetzen. Viele Tests zur Identifikation von Schwachstellen können automatisiert und damit organisch in den Entwicklungsprozess integriert werden. Dieser Artikel zeigt, welche Arten von automatisierten Testverfahren es gibt und stellt eine Auswahl von Werkzeugen mit Fokus auf Open-Source-Tools vor. Wir schauen uns außerdem an, wie sich diese Werkzeuge mit wenig Aufwand in den CI/CD-Prozess integrieren lassen, und beleuchten, wo ihre Grenzen und Fallstricke liegen.

Die Testarten

Es steht eine große Zahl an Open-Source- und kommerziellen Werkzeugen zur Verfügung, die man manuell zur Prüfung von Schwachstellen aufrufen kann, die sich aber zum größten Teil auch sehr gut automatisieren lassen. Diese Werkzeuge können in sechs Gruppen eingeordnet werden:

1. Software Composition Analysis (SCA), Prüfung der Abhängigkeiten: Moderne Systeme werden nicht von Grund auf neu geschrieben, sondern viele Basisfunktionen werden als Bibliotheken genutzt. Das gilt nicht nur für den Anwendungscode, sondern im Fall von Docker auch für Betriebssystemfunktionen und Programme. Diese Bibliotheken können bekannte Schwachstellen haben, die sich für Angriffe nutzen lassen.

2. Static Application Security Testing (SAST), statische Codeanalysen: Im Code lassen sich durch regelbasierte Suchen viele Probleme erkennen, z. B. Injections oder schwache Verschlüsselung. Es existieren Werkzeuge für alle gängigen Programmiersprachen und auch Infrastructure as Code (Dockerfiles, Helm Charts, Terraform, …).

3. Secrets Detection (SD), Suche nach Geheimnissen: Geheimnisse wie Passwörter oder API-Keys dürfen nicht mit dem Code in Repositories eingecheckt werden, und es gibt Werkzeuge, die z. B. Git Repositories über die gesamte Versionshistorie nach solchen Geheimnissen durchsuchen.

4. Infrastrukturtests: Auch die laufende Infrastruktur wie z. B. die Konfiguration von Cloud-Infrastrukturen, Kubernetes-Cluster, aber auch klassische Rechenzentrumsinfrastrukturen lassen sich sowohl mit Innensichten (Prüfungen, die innerhalb der Infrastruktur laufen) als auch Außensichten (Prüfungen von außen über das Internet) auf Schwachstellen überprüfen.

5. Dynamic Application Security Testing (DAST), Dynamische Tests: Blackbox-Sicherheitstests, bei denen die Tests durch Angriffe auf eine Anwendung (typischerweise Webanwendungen oder APIs) von außen durchgeführt werden. Die Tests können passiv sein und nur nach Auffälligkeiten suchen oder aktive Angriffe auf das System durchführen.

6. Interactive Application Security Testing (IAST): IAST arbeitet innerhalb einer Anwendung durch Instrumentierung des Codes, um Probleme zu erkennen und zu melden, während die Anwendung läuft.

In diesem Artikel konzentrieren wir uns auf die ersten vier Gruppen von Prüfungen, die alle einen statischen Charakter haben. Sie lassen sich sehr gut in den Build-Prozess integrieren.

Looking for advanced methods to reduce Cybersecurity risks?

4 days of Keynotes, Sessions & Workshops in Munich, December 1 - 5, 2025

Discover now

Integration in CI/CD Pipelines

Ideal ist eine Integration dieser Tests direkt in die CI/CD Pipeline, sodass sie mit jedem Build durchlaufen werden und das Team so immer den aktuellen Stand kennt und schnell reagieren kann. Glücklicherweise sind quasi alle Testwerkzeuge für den Einsatz in Pipelines vorbereitet, sodass bei der Integration wenig Aufwand entsteht. Mit einem inkrementellen Ansatz, wie in Abbildung 1 gezeigt, können schnell erste Resultate gezeigt werden, die die Sicherheit des Systems verbessern.

Zum Start werden erste Werkzeuge in die Pipeline integriert, z. B. zur Prüfung der Abhängigkeiten im JavaScript-Code des Frontends oder zur statischen Analyse der Dockerfiles. Die Ausgabe der Ergebnisse erfolgt in einem lesbaren Format in der Konsole oder als Dateiexport. Damit kann das Team anfangen, die Ergebnisse der Prüfungen zu sichten und Schwachstellen zu beseitigen.
Die Analyse der Ergebnisse auf Basis von Konsolenausgaben oder Dateien ist mühsam. Häufig sind auch Ergebnisse zu finden, die im aktuellen Projektkontext False Positives darstellen, aber bei jedem Lauf der Pipeline wieder gemeldet werden. DefectDojo [2] ist ein Open-Source-Programm, das die Ergebnisse der Schwachstellentests einlesen kann und in einer Benutzeroberfläche darstellt. Darin können dann die Verwaltung und das Reporting der Schwachstellen erfolgen.

In weiteren Schritten werden zusätzliche Werkzeuge in die Pipeline aufgenommen, die mehr Informationen zu Schwachstellen erzeugen, bei deren Beseitigung das System noch sicherer gemacht wird.

Software Composition Analysis (SCA)

Viele Codebestandteile für neue Anwendungen stammen heute aus Bibliotheken. Diese können bekannte Schwachstellen enthalten, die Angreifer ausnutzen können. Das prüft man mit SCA. Die dafür verwendeten Tools nutzen verschiedene Quellen, z. B. die CVE-Datenbank [3] oder GitHub Advisories [4]. Kommerzielle Toolhersteller pflegen zusätzlich ihre eigenen Datenbanken mit Schwachstellen. Es stehen Tools für Anwendungen (Tabelle 1) und Infrastructure as Code (Tabelle 2) zur Verfügung.

Wie man mit den Ergebnissen umgeht

Die Aktualisierung einer betroffenen Komponente auf eine neuere Version ist häufig der einfachste und beste Weg, eine gefundene Schwachstelle zu beseitigen. Manchmal ist das aber nicht möglich, weil zum Beispiel die Schwachstelle in der Komponente noch nicht gefixt ist oder weil die Komponente eine transitive Abhängigkeit ist. In diesen Fällen gibt es mehrere Möglichkeiten, mit der Schwachstelle umzugehen:

1. Sicherstellen, dass die anfällige Funktion der Komponente nicht im System verwendet wird.

2. Einkapseln der anfälligen Funktion der Komponente im eigenen Code, damit die Schwachstelle nicht mehr von Angreifern genutzt werden kann.

3. Explizite Akzeptanz des Risikos.

Static Application Security Testing (SAST)

Programmierer können unbewusst Schwachstellen in ihren Code einbauen. Durch ein manuell gebautes SQL für eine Performanceoptimierung kann schnell eine Angriffsfläche für SQL Injections entstehen. Werden Ein- und Ausgaben in Weboberflächen nicht sorgfältig geprüft, kann ein Einfallstor für Cross-Site Scripting entstehen. Oder sensitive Daten sind durch falsche Konfiguration der Kryptografie nur schwach verschlüsselt. Mit regelbasierten Suchen lassen sich viele dieser Probleme erkennen. Es existieren Werkzeuge für alle gängigen Programmiersprachen (Tabelle 3) und Infrastructure as Code (Tabelle 4).

Wie man mit den Ergebnissen umgeht

Wenn eine gefundene Schwachstelle nicht als False-Positive-Meldung eingestuft wird, ist es immer sinnvoll, den Source Code entsprechend zu ändern, um die Schwachstelle zu entfernen. Die Werkzeuge geben dabei häufig Hilfestellung, indem sie Beispiele für eine korrekte Implementierung enthalten.

Secrets Detection (SD)

Geheimnisse wie Passwörter oder API-Keys sind schnell einmal im Code-Repository eingecheckt. Beispiele dafür sind Informationen, die im Code hart verdrahtet wurden oder ein versehentlicher Commit einer Konfigurationsdatei. Wenn das Code-Repository nicht sehr strikt beschränkt, wer darin lesenden Zugriff hat, können dadurch möglicherweise weitreichende Angriffsstellen entstehen, mit denen z. B. Unbefugte direkt auf Datenbanken oder Schnittstellen zugreifen können. Solche Daten dürfen also nicht mit dem Code in Repositories eingecheckt werden, und es gibt Werkzeuge, die z. B. Git Repositories über die gesamte Versionshistorie nach solchen Geheimnissen durchsuchen (Tabelle 5).

Wie man mit den Ergebnissen umgeht

Es reicht nicht aus, das Geheimnis aus dem Code oder der Konfigurationsdatei zu entfernen und eine neue Version in das Repository einzuchecken. Da die Information weiterhin in den vorherigen Versionen sichtbar ist, müssen die Passwörter oder API-Keys selbst in den Konfigurationen geändert werden. Das kann viel Aufwand bedeuten, ist aber der einzige Weg, die Systeme in diesen Fällen sauber abzusichern.

Infrastrukturtests

Die vorher beschriebenen Tests werden in die CI/CD-Pipeline eingebunden und liefern Ergebnisse direkt im Entwicklungsprozess. Es kann aber auch die installierte Infrastruktur selbst geprüft werden. Die eingebauten Werkzeuge der großen Cloud-Provider sowie Open-Source-Tools erzeugen eine Innensicht auf mögliche Schwachstellen in der Konfiguration (Tabelle 6).

Wie man mit den Ergebnissen umgeht

Wie auch bei den anderen Prüfungen muss zunächst eine Bewertung erfolgen, wie relevant die Meldung im aktuellen Kontext ist. Eventuell soll eine im Internet zu erreichende Ressource tatsächlich öffentlich zu erreichen sein, oder es ist eine Fehlkonfiguration, die behoben werden muss. Wenn die Einrichtung der Umgebung mit Infrastructure as Code geschieht, können bereits in einer Entwicklungs- oder Testumgebung viele Probleme gefunden werden, was dann zu einer sicheren Einrichtung der Produktionsumgebung führt. Dennoch sollten in allen Fällen die Schwachstellentests auch auf der produktiven Umgebung durchgeführt werden.

Grenzen und Fallstricke

Mit den hier vorgestellten Vorgehensweisen und Werkzeugen kann man die Sicherheit eines Softwaresystems stark verbessern. Man muss sich aber auch der Grenzen und Fallstricke bewusst sein.

Sicherheit im Design

Auch wenn die genannten Werkzeuge ein integraler Bestandteil der Entwicklung sein sollten, fängt Sicherheit dennoch früher im Entwicklungsprozess an. Die Anforderungen an Sicherheit müssen klar definiert sein. Um diese zu ermitteln, helfen Schutzbedarfs- und Bedrohungsanalysen und daraus abgeleitete Risiken. Die Sicherheitsanforderungen werden in den User Stories und der Definition of Done verankert und sind damit auch Bestandteil der Architektur des Systems.

Automatisierte Prüfungen vs. Sicherheitstests

Die automatisierten Prüfungen können nur einen Teil der Schwachstellen erkennen. Wenn die Sicherheitsanforderungen aber in den User Stories und der Definition of Done beschrieben sind, wird es ein natürlicher Prozess, diese Anforderungen auch mit den verschiedenen im Projekt etablierten Testmethoden zu überprüfen, von Unit-Tests über Integrationstests bis Ende-zu-Ende-Tests.

Auch Penetrationstests haben weiterhin ihre Berechtigung. Mit einer Mischung aus automatisierter Schwachstellenerkennung und expliziten Tests der Sicherheitsanforderungen verlieren Penetrationstests aber ihren Schrecken und werden mehr zu einer Bestätigung, dass die Maßnahmen für sicheres Design und Entwicklung funktionieren.

Auswahl der Tools

Die in den vorherigen Kapiteln aufgezählten Tools sind nur eine kleine Auswahl. Es gibt viele weitere Tools, sowohl als Open Source als auch kommerzielle Produkte. Open-Source-Tools können schon gute Ergebnisse liefern, kommerzielle Produkte haben jedoch häufig bessere Analysemethoden und Managementoberflächen, für die man allerdings auch bezahlen muss.

Wie viel Aufwand man in die Auswahl von Tools investiert und ob kommerzielle Produkte notwendig sind, hängt letztendlich von den Sicherheitsanforderungen ab. Für niedrige bis mittlere Anforderungen wird ein kurzer Auswahlprozess von Open-Source-Tools vollkommen ausreichen, damit kann man mit wenig Investition die Sicherheit deutlich verbessern. Bei höheren Sicherheitsanforderungen, oder wenn man nicht für ein einzelnes Projekt, sondern auf Unternehmensebene denkt, ist auch ein höherer Aufwand für die Werkzeugauswahl und die Investition in kommerzielle Produkte gerechtfertigt.

False Positives

False Positives sind gemeldete Schwachstellen, die im aktuellen Kontext keine Beeinträchtigung der Sicherheit darstellen. Insbesondere die statischen Codeanalysen neigen dazu, viele False-Positive-Ergebnisse zu produzieren, aber auch bei den anderen Klassen der Werkzeuge treten sie auf. Bei der Konfiguration der Tools gibt es zwei Möglichkeiten, ihre Anzahl zu reduzieren:

1. Ausschluss von Code, der zur Laufzeit nicht ausgeführt wird (z. B. Testcode oder Eingaben für die Codegenerierung) und eingebundenem Code wie JavaScript-Bibliotheken (z. B. jQuery oder Bootstrap)

2. Anpassung der Regelsätze der Scan-Engine; man kann zum einen Regeln für Bedingungen deaktivieren, die im aktuellen Kontext als sicher gelten können, oder bestehende Regeln ändern, damit sie besser zum Code passen

Wird DefectDojo zum Management der Schwachstellen eingesetzt, können die False Positives auch dort markiert werden. Damit entfällt ihre Behandlung für die Zukunft.

Bewertung und Priorisierung

Idealerweise wird man die Prüfungen zum Start des Projekts in die CI/CD-Pipeline einbauen. So kann man gefundene Probleme schnell beseitigen und es entstehen gar nicht erst lange Listen an abzuarbeitenden Problemen. Werden die Prüfungen erst aufgesetzt, wenn die Codebasis schon größer ist, erhält man typischerweise zunächst einmal eine längere Liste von gefundenen Schwachstellen. Diese müssen nach Relevanz bewertet und priorisiert werden. Dabei helfen die von den Werkzeugen vergebenen Schweregrade, sodass man sich von kritischen Meldungen zu den weniger schwerwiegenden durcharbeiten kann. Diese Schritte stellen einen Initialaufwand für das Projekt dar, der nicht unterschätzt werden darf und eingeplant werden muss.

Praktisches Beispiel

Wie sieht das Ganze in der Praxis aus? Eine kurze GitLab Pipeline zeigt, wie man eine Analyse der Abhängigkeiten und eine statische Codeanalyse mit wenig Aufwand einbinden kann.

Unser Beispiel-Service ist eine Spring-Boot-Anwendung, die mit Gradle gebaut wird. In der Datei build.gradle müssen wir nur einige zusätzliche Zeilen einfügen, um den OWASP Dependency Check für die Analyse der Abhängigkeiten und FindSecBugs für die statische Codeanalyse aufzurufen (Listing 1).

plugins {
  ...
  id "org.owasp.dependencycheck" version "6.5.0.1"
  id "com.github.spotbugs" version "4.7.9"
}
 
...
 
dependencies {
  ...
  spotbugsPlugins 'com.h3xstream.findsecbugs:findsecbugs-plugin:1.11.0'
}
 
dependencyCheck {
  format='ALL'
}
 
spotbugs {
  ignoreFailures = true
}

In unserer GitLab CI/CD Pipeline führen wir drei zusätzliche Schritte ein, die in Abbildung 2 zu sehen sind:

Abb. 2: Pipeline mit Schwachstellentests

1. checkVulnerabilities führt sowohl die Prüfung der Abhängigkeiten als auch die statische Codeanalyse durch. Diese Prüfungen könnte man natürlich auch direkt beim Bauen der Anwendung durch Gradle aufrufen lassen. Die Berichte werden im Ordner build\reports abgelegt, dessen Inhalte als Artefakte für die nachfolgenden Schritte gespeichert werden.

2. import_findsecbugs und import_dependency_check importieren die gefundenen Schwachstellen in DefectDojo. Dazu nutzen wir den dd-import-Wrapper [5], der die benötigten Konfigurationen in DefectDojo bei Bedarf selbst anlegt und die API-Parameter als Umgebungsvariablen abfragt (Listing 2), was sehr gut zu der Definition von CI/CD Pipelines passt.

Damit stehen alle Ergebnisse in DefectDojo zur Auswertung und zur weiteren Behandlung bereit (Abb. 3). Typische Maßnahmen sind:

variables:
  DD_PRODUCT_TYPE_NAME: "Research and Development"
  DD_PRODUCT_NAME: "Example Service"
  DD_ENGAGEMENT_NAME: "GitLab"
 
stages:
  - check
  - import
 
checkVulnerabilities:
  stage: check
  image: openjdk:11-jdk
  script:
    - chmod u+x gradlew
    - ./gradlew dependencyCheckAnalyze spotbugsMain
  artifacts:
    paths:
     - build/reports/
    when: always
    expire_in: 1 day
 
import_findsecbugs:
  stage: import
  image: maibornwolff/dd-import:1.0.3
  needs:
    - job: checkVulnerabilities
      artifacts: true  
  variables:
    GIT_STRATEGY: none
    DD_TEST_NAME: "FindSecBugs"
    DD_TEST_TYPE_NAME: "SpotBugs Scan"
    DD_FILE_NAME: "build/reports/spotbugs/main.xml"
  script:
    - /usr/local/dd-import/bin/dd-reimport-findings.sh
 
import_dependency_check:
  stage: import
  image: maibornwolff/dd-import:1.0.3
  needs:
    - job: checkVulnerabilities
      artifacts: true  
  variables:
    GIT_STRATEGY: none
    DD_TEST_NAME: "Dependency Check"
    DD_TEST_TYPE_NAME: "Dependency Check Scan"
    DD_FILE_NAME: "build/reports/dependency-check-report.xml"
  script:
    - /usr/local/dd-import/bin/dd-reimport-findings.sh

• Die Auffälligkeit bleibt offen und soll im Code oder durch Aktualisierung einer Bibliothek beseitigt werden.

• Die Auffälligkeit ist ein False Positive und kann geschlossen werden.

• Die Auffälligkeit wird durch andere Maßnahmen mitigiert und kann geschlossen werden.

• Das durch die Auffälligkeit entstandene Risiko wird akzeptiert.

Diese Entscheidungen bleiben stabil, wenn bei weiteren Läufen der Pipeline die Ergebnisse neu importiert werden, d. h. geschlossene Auffälligkeiten bleiben mit ihrer Begründung geschlossen. Zusätzlich werden Auffälligkeiten automatisch geschlossen, wenn sie beispielsweise durch eine Änderung nicht mehr im Code enthalten sind und somit keine Meldung mehr entsteht. So reduziert sich die Menge der offenen Auffälligkeiten mit der Zeit und reflektiert, dass die Sicherheit des Systems wächst.

Abb. 3: Verwaltung der Schwachstellen mit DefectDojo

Fazit

Automatisierte Schwachstellentests können gut in bestehende CI/CD Pipelines integriert werden und helfen, frühzeitig mögliche Sicherheitsprobleme zu vermeiden. Initialaufwände entstehen bei Auswahl und Konfiguration der Tools und bei ersten Prüfungen. Diese Aufwände schwingen sich aber schnell ein und das Reagieren auf Schwachstellen wird Teil der laufenden Entwicklung.

Anwendungen, die geschäftskritische Vorgänge abwickeln oder sensible Daten verwalten, sollten Schwachstellentests der hier vorgestellten Kategorien einsetzen. Mit weiteren sicherheitsrelevanten Maßnahmen wie Architektur- und Codereviews, funktionalen Sicherheitstests und Penetrationstests ergibt sich eine optimale Absicherung der Anwendung gegenüber Angriffsversuchen.

The post Vulnerability-Management – Automatisiertes Management von Schwachstellen appeared first on IT Security Summit.