Roland Liposinović, Security Governance Generalist at Infobip, sees a critical shift: security should no longer be an afterthought or a compliance checkbox:

Make security a growth tool, not a tax. Build safety in from day one, and audits finish faster, big customers say yes sooner, and purchasing roadblocks disappear.

This mindset shift is one many organizations still struggle to make.

Too often, security is treated as a necessary evil, something to appease auditors and regulators. But Roland argues that security-first development is a competitive differentiator. By integrating controls early, companies can unlock new markets more quickly, shorten sales cycles, and establish trust in ways that directly impact the bottom line.

Security isn’t red tape. It’s quality control for modern, AI-powered products. Trust drives sales. Secure design grows trust over time.

Embed security across the entire development lifecycle

The question, then, is how to embed these practices across the entire software development lifecycle, from planning and coding to testing, deployment, and operations, without slowing down AI-driven innovation.

Roland’s answer is to make security invisible, automated, and developer-friendly.

“Think automatic seatbelts, not checklists,” he says. At Infobip, the team embeds rules directly into their cloud setup and delivery pipelines, ensuring that “the safe way happens by default.” Automated checks scan for vulnerabilities, exposed secrets, risky dependencies, and unvetted model files every time developers save code. If something is off, the build fails fast with clear feedback.

Feedback should arrive in minutes while developers are still working, not days later. Security runs next to the team, not in front of it, blocking the door.

One additional thing you can do before major projects is run lightweight risk assessments focused on a few key questions: How could this feature be misused or abused? What data does it touch? Who could misuse it? This practice, repeated whenever something changes, enables threat modeling to remain fast and continuous.

When it comes to testing, you should test like attackers would. “We throw malicious prompts, poisoned data, and guardrail-breaking attempts at our AI systems before release,” he says. “If our AI misbehaves, we fix it before anyone else can exploit it.”

Make it zero-trust!

AI helps defenders, but it also helps attackers. Adaptive phishing, deepfakes, and model inversion attacks are no longer hypothetical – they’re real. Roland advocates for a layered defense strategy that combines privacy-preserving techniques, governance frameworks, and culture change.

For model inversion, he points to regularization techniques, API access controls, and specialized defenses such as trapdoors to misdirect attackers.

However, data discipline matters just as much: teams minimize personal data, de-duplicate records, and apply strong consent and retention policies before training models. On the human side, Roland is blunt:

Make it zero-trust. Strong login, least privilege, and constant verification for people, services, and AI models.

His team conducts frequent, audience-tailored awareness sessions and real-world drills, ranging from deepfake scenarios to phishing simulations, so that employees can recognize emerging threats.

Strict communication rules help as well: sensitive actions like payments, access changes, and data requests must go through verified channels with two-person approval, never via informal messages or DMs.

If a request is urgent and secret, slow down. We give staff explicit cover to pause and verify even if it is “the CEO” on the line.

Security isn’t a cost center – it’s a revenue enabler

Roland emphasizes measurement as the bridge between technical controls and leadership buy-in. He recommends tracking metrics such as time to close deals, incident rates, audit duration, and verification rates before taking high-risk actions. Mapping controls to established frameworks, such as CIS Controls v8, NIST 800-53, and ISO 27001/27002, streamlines audits and makes funding more defensible.

When you can prove that certifications and clear proof of controls shorten sales cycles and open partnerships, suddenly security isn’t just a cost center. It’s a revenue enabler.

Treat the pipeline like production

As AI accelerates software delivery, the CI/CD pipeline has become the beating heart of modern development, but it has also become an increasingly attractive target for attackers. Roland warns that organizations can’t afford to treat their delivery pipelines as second-class citizens.

Treat the pipeline like production. It runs the factory, protect it like crown jewels.

Securing automated delivery flows starts with proof, not trust. Only signed code, images, and models are allowed through. “If it isn’t signed, it doesn’t ship,” he emphasizes. The system automatically scans dependencies, containers, secrets, and cloud configurations, and it halts the build immediately when it finds critical issues.

Teams isolate access using short-lived tokens and separate runners, eliminating the need for “kubectl from a laptop” shortcuts. The pipelines themselves are under constant surveillance.

Alert on strange runner behavior or workflow changes. If something looks off, pause and investigate before it spreads.

Track behavior, not just components

This rigor extends beyond internal code. As AI ecosystems grow more interconnected, the supply chain, spanning third-party libraries, pretrained models, datasets, and vendors, has become a prime target for sophisticated attacks. Roland advocates for a “trust, but verify” posture.

Track what’s inside. Ship an SBOM with every release, apps, containers, and model bundles, so you know every ingredient.

Teams must sign and verify every artifact, from model files to data packages, before using it. Teams don’t take third-party components at face value; they vet vendors for lineage, update habits, and incident history, and they require formal attestations.

Pretrained or open-source models are quarantined by default until they are scanned, wrapped, and continuously monitored for security vulnerabilities. Once the system is in production, teams can track behavior in real-time.

Don’t just list components, watch what they actually do.

Classify your AI by risk

With the EU AI Act and new data protection laws reshaping the regulatory landscape, Roland sees compliance not as a scramble at launch but as an architectural principle.

Design for the EU AI Act and friends from day one. Classify your AI by risk, attach the right controls, and plan human oversight where it is required.

This regulatory-first mindset drives concrete engineering practices: teams bake data minimization and purpose limitation into schemas and pipelines, not just policy documents. Model cards, decision logs, and clear appeal paths make AI decision-making explainable for both auditors and end users. Teams maintain immutable logs and model lineage with retention policies that align with legal obligations.

Be audit-ready, always. It’s much cheaper than retrofitting compliance later.

Get all signals in one place

As attackers adapt their tactics in real time using AI, defensive strategies must also become equally dynamic. Roland emphasizes the importance of observability, telemetry, and AI-driven defense in detecting anomalies before they escalate.

“Get all signals in one place,” he says. Teams aggregate logs from endpoints, identity systems, APIs, data jobs, and models into a single observability layer. Crucially, security teams monitor not just applications but the models themselves, tracking drift, unsafe outputs, and suspicious prompt behavior.

Detection should be trained on your own operational environment rather than generic threat baselines, so anomalies stand out quickly. When something triggers, automated playbooks in SOAR systems can take immediate action: isolating systems, rotating secrets, revoking tokens, or rolling back versions within minutes.

You can’t wait for a human ticket queue when the attack is adapting on the fly.

Make security a team habit

For all the technology and governance, Roland insists that the real force multiplier is culture. Security can’t live in a silo, it has to become a team habit.

Plant security champions in every squad. Peer-to-peer help beats one central bottleneck.

Regular tabletop exercises tied to real-world projects, such as handling deepfake scams, leaked credentials, or prompt injection attacks, keep teams alert and well-practiced.

Teams can also use positive reinforcement: they can celebrate clean audits, sharp threat models, and early bug catches publicly. To make good behavior the default, Infobip provides “paved roads,” opinionated templates, and secure defaults that make the safe path the easiest one.

With these layered strategies Roland is helping redefine what “secure AI” looks like in practice.

Security isn’t a brake on innovation. It’s what lets you innovate safely and keep that advantage.

The post Want Better Security? Test Like Attackers Would appeared first on ShiftMag.

Without proper cryptography, the answer is often yes.

It doesn’t take much for attackers – an exposed API, a weak hash, or sloppy design can open the door to stolen data, cracked passwords, or injected queries. The risks are real, and the cost of neglect is steep.

That’s why cryptography isn’t a bonus feature. In this article, we’ll dive into the different kinds of encryption you’ll encounter, and walk through how to weave these techniques into your Node.js applications in practical, secure ways – together with Yonatan Mevorach, Developer Advocate at Wix.

The different kinds of encryption and what they do

Think of cryptography as secret-keeping with math – the art of turning plain information into puzzles only the right key can solve. It’s built on a few core principles that Yonatan emphasizes:

• Confidentiality: Ensuring that information is only accessible to authorized parties.
• Integrity: Guaranteeing that data remains unaltered during transmission or storage.
• Authentication: Verifying the identity of users or systems.
• Non-repudiation: Preventing entities from denying actions they have taken.

These principles shape how secure systems are built and come to life through encryption and cryptographic algorithms. At its core, encryption takes readable data and scrambles it into ciphertext, keeping it safe from prying eyes. In his lecture at the Heapcon conference, Yonatan outlines the main approaches commonly used in modern development:

1. Symmetric Encryption: Uses a single key for both encryption and decryption. Examples include AES (Advanced Encryption Standard) and DES (Data Encryption Standard)
2. Asymmetric Encryption: Uses a pair of keys (public and private) for encryption and decryption. Standard algorithms include RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography)
3. Hashing: Converts data into a fixed-length hash value, which is irreversible. Examples: SHA-256 (Secure Hash Algorithm), Bcrypt, and Argon2 for password hashing.
4. Hybrid Encryption: Combines symmetric and asymmetric encryption to balance performance and security. A common implementation is TLS (Transport Layer Security).
5. Key Derivation Functions (KDFs): Used to derive strong cryptographic keys from passwords or other input values. Examples include PBKDF2 (Password-Based Key Derivation Function 2), Argon2 (Winner of the Password Hashing Competition), and Scrypt (Designed to resist hardware-based attacks).

KDFs are crucial for securely storing passwords and generating encryption keys that are resistant to brute-force attacks.

Securing your apps with Node.js, crypto modules, and modern encryption

As Mevorach explains, developers integrate encryption and cryptographic techniques into applications across various domains:

• Secure Communications: Protocols like SSL/TLS secure web traffic and APIs.
• Data Protection: Encrypted databases and file systems (e.g., AES-encrypted storage in cloud environments).
• Authentication & Access Control: Multi-factor authentication (MFA), digital signatures, and cryptographic tokens.
• Blockchain & Cryptocurrencies: Cryptographic hashing secures transactions and smart contracts.

Role of the Crypto Module in Node.js

In Node.js, the crypto module provides a set of cryptographic functionalities, including hashing, encryption, and key generation, ensuring to read the official documentation for detailed API usage.

It is widely used in web applications, authentication systems, and secure communication protocols.

Developers can leverage the crypto module to implement secure password storage, encrypt sensitive data, and integrate robust security mechanisms into Node.js applications.

Diffie-Hellman Key Exchange:

This solution solves the key distribution problem by allowing two parties to establish a shared secret over a public channel.

The process? User 1 and User 2 exchange public keys derived from private keys. Each uses the other’s public and private keys to compute the shared secret. Implementation in Node.js uses “crypto. create Diffie-Hellman.”

Developers can protect user data!

“Security best practices are simple in principle but critical in execution. Use proven algorithms like AES-256 and RSA, derive keys securely, and avoid weak or guessable passwords. Always rely on cryptographically secure random generators.”

That said, cryptography comes with its own challenges: key management, performance overhead, and evolving threats. Still, if you follow these best practices, you’re giving your software and your users real protection:

• Use well-established cryptographic libraries (e.g., OpenSSL, Bouncy Castle).
• Regularly update algorithms to mitigate vulnerabilities.
• Implement proper key management (e.g., Hardware Security Modules, cloud-based KMS solutions).
• Apply encryption at rest, in transit, and during processing where necessary.

So, as cyber threats become more sophisticated, encryption remain tools for secure software development. By integrating strong encryption practices and following industry standards, developers can build trustworthy systems that protect user data and maintain system integrity.

The post Can Anyone See This Password? Probably Yes – Unless You Encrypt It appeared first on ShiftMag.

As organisations navigate security fatigue and resource constraints, one bright spot remains: the growing adoption of pre-commit and build system security, signalling a proactive shift toward early vulnerability detection.

The software security landscape is increasingly focused on shifting left – the practice of detecting vulnerabilities earlier in the development lifecycle. This becomes more critical as we depend on AI to develop code, with the potential to introduce serious vulnerabilities if the technology is not implemented correctly. According to Snyk’s 2024 Open Source Security Report, the industry is at a crossroads, facing mounting security challenges that include diminished engagement in security practices, immature open source supply chain security practices, and a blind trust in AI-generated code.

Thankfully, supply chain security has also demonstrated consistent growth in the distribution of security tooling across the entire software development process. Most notably, pre-commit and build system security checks have seen a significant year-over-year increase (11.6% and 15.9%, respectively), reinforcing their critical role in identifying risks before they cause much bigger issues.

The growth of pre-commit and build system security

Developers are increasingly embedding security checks into pre-commit workflows and build systems, and for good reason. By integrating security measures earlier in the development journey, dev teams can avoid the need for costly and complex remediation. Vulnerabilities discovered later down the line could require extensive patches, emergency responses, or sometimes even damage control for compromised systems.

Pre-commit security checks act instead as a frontline defence, ensuring potential threats are addressed before code is committed. Similarly, robust build system security enhances supply chain integrity by verifying dependencies, automating vulnerability scans, and enforcing security policies within the build process. This is especially critical in AI workflows, where unchecked open source dependencies used for data pre-processing, model training, or inferencing can create security blind spots.

Implementing shift-left security effectively

To maximise the benefits of early vulnerability detection, organisations must ensure that pre-commit and build security measures are automated and seamless. Developers should not have to manually trigger security scans. Instead, automated checks integrated into pre-commit hooks and build pipelines ensure consistent enforcement without disrupting workflows.

It’s vital that security tools are comprehensive and context-aware. Tools should provide meaningful insights, helping developers to understand and solve issues without unnecessary friction or increasing cognitive load. This remains crucial for successful DevSecOps strategies and for AI teams navigating complex dependencies across data science and engineering. The report notes AI development is increasingly dependent on open source tools and libraries, which makes securing these dependencies non-negotiable.

Of course, shifting left also requires more than just tools; it requires cultural change within organisations. Building empathy and common goals among development, operations and security teams fosters collaboration and shared responsibility, helping businesses to work together more cohesively – and therefore more securely.

Security measures should be continuously updated. Given the dynamic nature of open-source vulnerabilities, pre-commit and build system security needs to rely on continuously updated databases and intelligence feeds.

Integrating security throughout the development process

Beyond pre-commit and build security, the steady growth in security integration across code repositories (up 10.3%), CI/CD pipelines (up 6.3%), and CLI security tools (up 5.8%) underscores the importance of securing every stage of the development process.

By embedding security measures directly within repositories, for example, organisations can enforce policies such as branch protection, commit signing, and automated vulnerability scanning. These proactive measures help detect potential security flaws, outdated dependencies, and misconfigurations before code is merged, reducing the risk of vulnerabilities making their way into production. For AI, this means securing everything from model configuration files to training scripts and data ingestion logic.

Meanwhile, CI/CD pipelines help developers automate testing, deployment, and infrastructure provisioning, providing a critical point for embedded security checks. CI/CD workflows enable teams to conduct automated security testing, such as Static Application Security Testing (SAST), Software Composition Analysis (SCA), and container scanning, once again ensuring vulnerabilities are identified and fixed as soon as possible.

Finally, command-line interfaces provided by CLI security tools remain a preferred environment for many developers, and integrating security tools within CLI workflows ensures security checks become a natural part of development. Security should naturally be accessible, developer-friendly and seamlessly integrated into existing workflows, and CLI tools make a big difference.

The road ahead

The increasing adoption of pre-commit and build system security measures as the software industry shifts left remains a promising sign of proactive risk management.

Organisations that invest in early detection mechanisms will not only strengthen their security but also drive greater efficiency and resilience in software development itself. For AI in particular, where trust and reliability are vital, securing the open source supply chain from the start is critical. By embedding security checks where they matter most – before vulnerabilities can take hold – teams can ensure that shift left is done right.

The post Shift left done right: Driving early vulnerability detection through pre-commit and build system security appeared first on ShiftMag.

How can a single update of antivirus software interrupt air travel, TV broadcasts, office work, retail stores, and emergency services, all on the same day and across the globe?!

That was the question on everyone’s mind on July 19th, after it became clear that CrowdStrike’s update of the sensor configuration of its antivirus software Falcon was the reason behind all of those blue screens of death.

In a promptly published public statement on technical details of the incident, CrowStrike says:

We understand how this issue occurred and we are doing a thorough root cause analysis to determine how this logic flaw occurred. This effort will be ongoing.

The whole world is curious to find out why this particular software update didn’t go through standard engineering practices. CrowdStikes promised to update its root-cause analysis as the investigation progresses.

“Fortunately, in the last decades of IT engineering, it has been established that companies of high esteem, such as CrowdStrike, publicly disclose technical and organizational details that led to incidents so that others may learn from their mistakes. I’m sure it will be an interesting and educational story.”, says Mihovil Madjer, Product Director at Infobip.

How come it doesn’t happen more often?

Madjer explains that big tech companies like CrowdStrike usually have engineering practices to prevent incidents like that. Before changes to software are pushed to all customers, the new version usually goes through several safety and risk prevention/reduction steps:

“First, the change is tested in a lab environment to ensure it won’t break the software or system and that it behaves as intended. The Friday incident appears to have affected all Windows machines, but that’s not always the case. Sometimes, software can affect only certain versions of Windows. Since lab testing can only include a finite combination of software and hardware versions, additional steps are usually taken to ensure as little of a customer base is affected as possible.”

Canary deployment

Madjer says a technique called canary deployment can be used to send the update to just a fraction of customers and compare its behavior against the old version of software running on the customers’ side.
Lastly, even if the canary doesn’t show any issues, the new version is usually rolled out gradually to customers, a few percent at a time, and monitored for any defects.

Any of these techniques would have prevented such a vast impact on the global scale. It appears the new version of the software was pushed instantly to all customers without testing.

YOLO deployment

“Push all software to all customers without testing” is what Gergely Orosz of The Pragmatic Engineer called YOLO Deployment:

“YOLO deploys are fine when you don’t care much if a deploy goes wrong, and it’s easy enough to revert. A deployment that could take down the majority of your customers is not one with which to experiment with this approach.”

As the IT people eagerly await for CrowStrike’s update on the root cause analysis, let’s use what has already been called “the largest IT outage in history” as a wake-up call and a reminder to examine our own processes and workflows.

The post How could that happen: All eyes on CrowdStrike post mortem appeared first on ShiftMag.

Application security is a major concern these days, with organizations like OWASP highlighting how bad things actually are. At the same time, application development practices have also changed significantly with the rise of the “Shift Left” approach, which pushes security considerations earlier in the process.

The challenge of Shift-Left

Now, don’t get me wrong—”Shift-Left” is great. Integrating security early in the software development process is a good, proactive mindset that prevents problems rather than dealing with them after they occur.

The thing is, most security vulnerabilities are being found in the code, and that’s where DevSec and DevSecOps come in.

The rise of DevSec

With the rise of DevSec and DevSecOps, developers are now expected to take an active role in security, using various tools and taking responsibility for it. While that might sound promising, the facts are simple:

Security is extremely hard, and nobody really likes doing it.

The responsibility, though, as I mentioned, is in the hands of the developers, and it’s them who need to find a way to balance feature development with maintaining a strong security posture.

So, how can we help developers? What can help them focus on app development, maintain security best practices, and have a good time overall? The answer, I believe, lies in improving the Developer Experience (DevEx).

By making security tasks more intuitive and naturally integrated into the development workflow, developers can handle security effectively without disrupting their application development workflow. Let’s take a look at how:

The solution: Developer Experience (DevEx)

Improving Developer Experience (DevEx) is the key to helping developers manage security. We discovered this through our work with authorization. With applications’ ever-growing complexity and microservice-based architectures’ growing popularity, permissions have become a major security concern in recent years, with developers expected to handle models like RBAC, ABAC, and ReBAC.

The problem with these requirements is that they often don’t fit into the typical development workflow, making authorization an extremely difficult challenge to tackle.

Case study: Fine-grained authorization

Our approach at Permit was to focus on simplifying these tasks from the application development side rather than just the security side. Instead of asking developers to start from scratch or learn complex security models, policy engines, and policy languages (Those who have dealt with OPA’s Rego know how complex it can get at first), we aimed to provide capabilities that developers can integrate into their existing workflows.

Offering a no-code UI for creating and managing authorization policies, and APIs that use familiar concepts like entities, resources, and data structures, for example, made it easier for developers to integrate security into their applications without becoming security experts.

They, of course, still need to understand how to utilize the system in the best way – but they can do so without developing intricate systems from scratch and without writing policy code – unless they really want to.

We chose to frame complex security concepts in terms that align with the development process, such as user and resource segmentation, which can be achieved based on conditions. Thus, instead of talking about ABAC, ReBAC, and Relationships, we make it intuitive for developers to configure security settings that match how their products work.

It has been our experience that making this accessible to developers makes it much easier for them to incorporate it into their application development workflow. Today, even though our product is based on concepts quite complex for the average software developer (We mentioned policy engines, policy-as-code, etc.), most of our users find it enough to work with our SDKs and no-code UI.

This approach makes security a natural part of application development.

In the end, by speaking the language of developers and simplifying security tasks, we help them focus on what they do best: building great applications. This results in a more enjoyable development process and, more importantly, better application security.

Not just developers

A good user experience in security doesn’t stop with developers; it extends to other stakeholders, including end users.

Who uses our application and the level of control they expect to have is a major factor to consider. Aside from end users, we’ve got dozens of stakeholders, including internal non-technical members of our organization, DevOps, RevOps, AppSec teams, developers, and, don’t forget, AI agents and non-human users.

These users each require their own level of access to the application; they need a way to safely delegate permissions and permission management, and these require good experiences. Why?

Poor user experience is one of the biggest vulnerabilities in security.

Bad user experience has a strong tendency to encourage users to make “shortcuts” – bypassing difficult-to-use security features. (For Example, Giving everyone Super-Admin because configuring actual roles takes too much effort) This compromises security.

By focusing on both developer and user experiences, we aim to cover the entire security circle, considering the needs of all stakeholders involved in using the application.

Embeddable Access Control components

An example of this is our “Access Requests” and “Approval Flows” embeddable components. We realized that developers needed more than just tools to model, configure, or audit security settings—they needed ways to give users a clear and manageable experience of controlling their data and actions within secure boundaries.

By offering these components, we provide users with an easy way to handle access control, ensuring data stays secure without needing to navigate complex security configurations. This approach helps prevent security shortcuts and enhances overall security by making it accessible and understandable to everyone involved.

Industry example: ArcJet’s DevEx approach

We’ve boasted our own methods enough – but we are not the only ones with this approach. ArcJet, for example, has adopted a developer-friendly model that embeds security into the development process very naturally. Instead of treating security as a separate layer that developers must manage, ArcJet provides an SDK that developers can integrate directly into their applications.

ArcJet’s bot detection tool, for example, doesn’t require developers to configure complex network security settings. Instead, it offers an SDK that can be used within the application development process. This allows developers to model better bot protection based on their specific use cases, making the security integration feel natural and straightforward.

By simplifying security and making it a part of the everyday development workflow, they help developers build secure applications without needing to become security experts.

A wholistic approach to DevEx

Security is undeniably crucial, and we need experts to lead the charge in security work and terminology. However, from our experience, it’s important to distinguish between market education and the actual product we provide. At Permit, we focus on creating a developer-oriented experience with our SDKs, ensuring they integrate smoothly into the Software Development Life Cycle (SDLC).

At the same time, we produce content that dives deep into security concepts like RBAC, ABAC, and ReBAC. By constantly engaging with the Identity and Access Management (IAM) community, we aim to bridge the gap between complex security ideas and practical developer tools.

A holistic view of DevEx encompasses the entire application development process, from initial SDK integration to CI/CD workflows and production. This is why we support both SDKs and Terraform. Some teams prioritize the product and use SDKs, while others focus on DevOps and CI/CD, modeling with Terraform or other Infrastructure as Code solutions.

A comprehensive approach to DevEx involves considering every step of the development process, ensuring no aspect is overlooked. This ensures that the experience remains seamless and efficient from the first developer building a POC to the final CI/CD implementation.

Enjoying the process

Enhancing DevEx is a powerful way to improve application security. By making security tasks easier and more integrated into the development process, we can help developers create secure, high-quality applications while enjoying the process.

The post Want developers to take care of security? Make it easier for them! appeared first on ShiftMag.

When we hear the word “hacker,” we immediately think of someone who uses his expertise and technical knowledge to gain unauthorized access to a computer system, exploiting its weaknesses and potential errors, often driven by malicious motives. Over time, a bad connotation has occurred due to frequent misuse and representation of malicious hackers in the media.

Hackers have the skill to create algorithms to crack passwords, penetrate networks, or disrupt network services. Malicious hacking primarily focuses on stealing valuable information or seeking financial gain. However, not all hacking activities are harmful. This brings us to ethical hacking. But what exactly does ethical hacking involve, and why is it relevant? Andreas Creten, CEO and Founding Partner at madewithlove, answered this question.

He and his team used ethical hacking techniques to break into an unmanaged legacy application for a customer. The developer of a critical application disappeared without leaving behind any documentation, so their only option was to hack the system! This was also the topic of his lecture at the Full Stack Europe conference in Antwerp, which took place this October, and after his talk, we had the following conversation.

When is hacking acceptable?

Andreas explained a situation in which a customer asked his company for help. According to his words, a customer approached them when they had lost contact with the developer who created their application. So, they needed to discover the hosting location of the application or identify the server’s manager.

As they were using the application as the mission-critical part of their company, they needed to change it and couldn’t reach him anymore. After they were rejected by a couple of agencies, Andreas and his team were asked to rebuild it from scratch:

We were like their last resort, and we sad OK, let’s try to figure out if we can work with what we have and get the data out of it because it’s of course, essential for them to get all the data, and the historical data as well.

They decided to hack their system ethically to retrieve the data for future use. From there, and as soon as they had the data hacked out of it, they rebuilt the whole application.

Of course, before all that, they tried to reach the developer who initially worked on the mentioned application, but it turned out that he could not be of any help to them:

We have been in contact with him, and it turned out he was in the hospital, but he was unwilling to cooperate with transferring the application. The customers were locked in functionally. They couldn’t get access to the service anymore. But also, from a legal perspective, the guy was unwilling to let go.

What distinguishes ethical hackers from regular ones?

Andreas explained that if the developer had only signed a paper and said: “ok, you can take over the application and get access to my servers,” it would have been a different situation because they wouldn’t need to hack it. But the developer kept declining to help. So they had to do it this way – to hack the system ethically.

Also, he highlighted the fundamental contrast between ethical hacking and just hacking. Ethical hacking involves identifying security vulnerabilities and reporting them to companies instead of causing harm:

It’s about discovering and utilizing security flaws for our customers’ benefit. Good intentions ultimately drive ethical hacking.

The main tool they used was SQL map

Their primary tool was SQL map, which exploited the SQL injection. After all, that’s the whole thing about hacking:

I showed an example of doing it for a good cause, but I could use the same thing to pull, let’s say, all the Belgians’ data out of the national system. I find a hole like that. So, we use the same tool and build the tooling around it to make it easier to get all the data out.

As he concludes, typically, a hacker wants to get one database table: the users, their email addresses, and phone numbers, so they can start phishing them. He and his team needed all the data because they wanted to rebuild the application.

The post Who’re you gonna call when you need to break into an unmanaged legacy app? Ethical hackers! appeared first on ShiftMag.

End-to-end encryption (E2EE) fortifies data by transforming it into an unreadable format using encryption keys, ensuring only authorized endpoints can decode it. This security measure shields sensitive information — like business documents, financial records, medical data, or personal conversations — during transmission.

Its importance lies in preventing cyber threats that cost businesses millions in breaches, encompassing response expenses, revenue loss, and reputational harm. E2EE doesn’t just encrypt messages. It enables strict control over data access through a centralized policy management system.

Combined with a key management protocol, it protects information at every stage, preventing breaches and preserving customer trust while attaching to regulatory compliance. Nevertheless, skepticism persists regarding the security of this system, particularly among individuals needing more technical expertise and familiarity with technology.

During his lecture “Maths or magic? End-to-end encryption explained like I’m five” at the Full Stack Europe conference we attended in October, Paolo Insogna (Core member at Node.js) clarified misunderstandings about end-to-end encryption, highlighting that decrypting the system would take roughly 100 years, making the accessed data irrelevant.

What is end-to-end encryption?

At the beginning of our conversation, Paolo made it clear: there are only two possible forms of encryption. One is the regular one, and one is the end-to-end. He explained that the biggest difference is if we have to transfer some data from point A to point B going through somebody in the middle. Usually, what happens is that we send the data to encrypt to somebody that decrypts the data and sends it to the other party.

He continued that this technique is way more secure because the data is never decrypted and is never readable by anybody who is not supposed to be the final recipient of the message, which then means that even if the data packets are hijacked or stopped in any way, there’s nothing you can do with those data:

For instance, the authorities can’t read that data because not even the company physically holding it can access it. Companies don’t possess the key to decrypted data.

To make his point even better, Paolo gave an example that is close to all of us. If we lose the password for online accounts at, say, Google or Apple and don’t have any recovery options, those companies wouldn’t be able to decrypt our accounts:

They are not capable of decrypting the data. The data is gone forever. They do not like it, but it’s just how it works.

Why is it important?

Then, we asked Paolo if all messaging apps needed to use E2EE, and he was emphatic: They should. He explained why – given the power of the devices, there is no harm in applying encryptions because they are very fast. So encrypting a very small text message takes a few milliseconds, and the same crypt takes a few mills:

There is no good technology excuse not to use this technique. On the other hand, I am aware of the state of consciousness of contemporary society. First, we have high-level security problems like national security problems caused by governments and state institutions not encrypting their data.

Paolo points out that this is a wrong point of view because problems arise when E2EE is not used, not because the technology is bad and permeable. The mathematics behind it is so secure that not even all the computing power of Facebook can decrypt your message. That’s why companies should trust technology:

Let me put it this way: nobody doubts that if an engineer builds a bridge, the bridge will stay up. They should trust developers as well.

Is it really secure?

Asked to explain how secure end-to-end encryption is, Paolo pointed out that the point of encryption is not that data could never be decrypted. That’s because, in the long run, if someone tried all possible combinations, they would discover the right one at some point.

The core idea is to make guessing the right combination so hard that decrypting it would take so long that the data eventually encrypted would become useless:

If you try to decrypt my health data by brute forcing, so you try every possible combination, it will take you 100 years in 100 years. I’m long dead.

Will faster computers be able to decrypt it?

The only thing potentially threatening end-to-end encryption is quantum computing, as those computers are way faster than the ones we currently use:

Quantum computers are way faster, and I’m talking a million times faster than today’s computers. So it becomes possible to decrypt the data much more rapidly.

However, this scenario is only possible if we keep the data encrypted today with slower computers and use faster computers to decrypt. Paolo points out that if we have faster computers to decrypt, we will have equally fast computers to encrypt. So, he believes there will be an equalization of forces in the future.

Finally, when we asked Paolo what steps engineers should take to ensure encrypted data in the future, he replied that as soon as they see these computers happening, they should eventually keep all the data they still care about, decrypt it, and replace it with more robust encryption.

The post End-to-end encryption explained as if you were five by Paolo Insogna appeared first on ShiftMag.

A study by SauceLabs surveyed 500 US-based full-time developers to find out how accurate the trope of the Lazy Developer is, what industry practices allow it to exist, and if the root cause of the “laziness” are developers themselves or there are some broader factors at play.

Developers were asked to anonymously voice their opinions and share their behavior on certain habits the Lazy Developer is often accused of. 

Proudly pushing to prod without testing

Per their answers, one of the findings was that developers don’t necessarily deny their Lazy Developer behavior. Some revel in it, sharing memes and anecdotes about recklessly pushing to prod. 

In their current role, over two-thirds of respondents (67%) admitted to pushing to prod without testing, while over a quarter (28%) of respondents regularly do so.

Almost the same percentage of developers surveyed, 61%, admitted to using untested code generated by ChatGPT, and more than a quarter of them (26%) do so regularly.

When split by age, the statistics showed that the more senior developers get, the less likely they are to do it. Respondents aged 58 or more said they have never or very rarely pushed to production without testing. The study leaves an open question, though, if the reason for that was that the more senior developers are wiser or just more obedient. 

Security, schmecurity

The report further reveals that 70% of survey respondents had used a coworker’s credentials in order to circumvent company restrictions for access to data and/or internal systems at their current job, and 41% of respondents do so regularly.

Even more shockingly, 75% of developers — 3 out of every 4 — admit to circumventing security protocols in their current role (such as disabling MFA or an unstable VPN) to complete a task, while 39% of developers report doing so routinely. 

Developers not only skip the security measures with the data they own, but also 60% confessed to sharing unredacted data with unauthorized individuals when troubleshooting or fixing a process. Additionally, 70% acknowledged sidestepping data encryption while transferring sensitive information to make the process faster or simpler.

Who is to blame? 

The study concludes that bad developer behavior is a systemic issue, not a broad conspiracy of individual malicious actors. Before blaming these so-called “lazy developers,” the study advises organizations to re-evaluate their testing processes and security protocols.

If developers are constantly taking shortcuts and security risks, that’s a sign that leaders need to set clearer expectations (that, or set goals more firmly planted in reality), and managers need to refine processes, tools, and provide the appropriate resources to achieve desired outcomes without sacrificing quality or safety. 

And, in the year of the mass tech layoffs, they offer one more piece of advice – don’t shift left by simply gutting your QA team and expecting developers to pick up the slack.

The post The Lazy Developer: Testing in production is real, but… appeared first on ShiftMag.

APIs are like an electrical plug, Sean Falconer, Head of Marketing at Skyflow, says:

As a user of an electrical plug, all I care about is making sure there’s electricity getting to my lamp so I’m not sitting in the dark. I don’t care about all the wiring that’s going on within the walls. That was done by an electrician with specific domain expertise. This is the same for an API.  

Companies with experts that solely focus on a specific problem can focus on solving that problem and then abstract the problem away by providing an API, he continues.

As a consumer of the API, I just need to understand familiar concepts like JSON, REST, API keys, etc. I don’t need to understand how Stripe communicates with card networks to validate whether a credit card is valid. The abstraction lets me leverage the utility of the API for my business or product without needing special expertise. That way my talent can focus on building our core product. 

Can we have API-based solution for data privacy?

We have APIs for sending text messages, carrying out money transfers, doing sentiment analysis, and even creating cat memes, but what about privacy? At Shift Conference in Miami Sean shared some unique challenges they had to face at Skyflow when creating API-based solution for data privacy.  At Shift Zadar he will speak on a pressing concern for more companies, that of implications of sharing their sensitive data with a generative AI model?

By leveraging the APIs built at Skyflow, you get to take advantage of the domain expertise of the people that built similar systems at Salesforce or someone with over 50 patents in database security and encryption, or people who did PhDs in homomorphic encryption. All you need to understand is how to make a REST API call or use an SDK.  

Privacy isn’t a feature or an afterthought

Privacy isn’t a feature, or an afterthought once you’ve built and scaled everything. It should be a day 1 priority; privacy needs to be part of the culture of a company.  

It’s everyone’s job within an organization. That means when you purchase a third-party tool, you need to be looking carefully at how that company’s tool secures and manages your customer’s data. Additionally, when you design and build products and features, privacy can’t just be a checkbox in the launch process, it needs to be part of the design cycle.  

How would you handle your passport?

He compares handling sensitive customer data to how you would handle your passport: you wouldn’t make thousands of copies, handle it in the clear or give others uncontrolled access to your passport.

Historically, Sean adds, companies have treated all data the same, regardless of whether it’s a click on a website or someone’s personal information, it’s just ones and zeros stuffed into a database somewhere within their infrastructure. Over the past 20 years, companies have built and scaled massive systems with millions and sometimes billions of users, never really paying attention to what they’re storing about users or where the data ends up. It’s all just data. 

What ends up happening is that the sensitive customer data is copied and fragmented throughout the entire system. Instead of just one copy of someone’s personal information, you have thousands of copies. Over time, you simply have no idea where and what you’re storing. If you don’t know where it is, or what it is, that makes it impossible to protect it and makes compliance impossible. 

To address this, companies attempt to apply various cybersecurity tools to lock down access, control the information flow, and support different use cases. However, this is like applying a bandage to a broken arm, it can’t fix the underlying problem. The arm is still broken, and these patchwork solutions to data privacy and security can’t fix the underlying infrastructure problem.  

As a result, even though companies spend millions of dollars on data security, they still continue to have data breaches and compliance issues.

Many companies are choosing to try to solve the problem of data security and privacy themselves. They underestimate the complexity of what they’re taking on, assuming that hashing or encrypting the data within their database will be enough. But solving these challenges is not the prime directive for most companies, so they lack the talent, domain knowledge, expertise, and focus required to really get a handle on the problem. 

How did Netflix, Apple, or Google solve this issue?

In his presentation at Shift Miami on May 23rd, Sean will delve into the complexities of ensuring data privacy, and discuss how tech giants like Netflix, Apple, and Google have tackled this issue by creating a pioneering technology called the zero-trust data privacy vault. 

Skyflow has drawn inspiration from these leading companies to create a data privacy vault accessible to everyone through a user-friendly API. I will walk the audience through the evolution of creating this API and demonstrate how to control access to sensitive data. 

The post What if privacy had an API with Sean Falconer of Skyflow  appeared first on ShiftMag.