research-article

Open access

A First Look into Software Security Practices in Bangladesh

Authors:

Ankit Shrestha,

Tanusree Sharma,

Pratyasha Saha,

Syed Ishtiaque Ahmed,

Mahdi Nasrullah Al-AmeenAuthors Info & Claims

ACM Journal on Computing and Sustainable Societies, Volume 1, Issue 1

Article No.: 8, Pages 1 - 24

https://doi.org/10.1145/3616383

Published: 22 September 2023 Publication History

PDF eReader

Abstract

Software security practices are critical in minimizing vulnerabilities and protecting unauthorized access to the code and the system. However, software security practices outside Western countries need to be better understood. This need for understanding security practices is further necessitated by the increased outsourcing of software development that can result in vulnerabilities on a global scale. This article addresses this gap, focusing on Bangladesh, a country that represents a booming software industry in the Global South. In this study, we conducted semi-structured interviews with 15 developers to understand their security perceptions and identify the factors influencing software security practices in Bangladesh. Our findings unpack how security fits in the local software development life cycle and shed light on the challenges deterring security practices in Bangladesh. Based on our results, we provide recommendations for developing situated and sustainable strategies to support software security practices in the local context.

1 Introduction

Software security refers to a set of practices that help protect software applications and digital solutions from attackers.¹ In the absence of such practices, security vulnerabilities are prevalent in source code, libraries, and Application Programming Interfaces [30, 31, 41, 46, 51, 57]. These security vulnerabilities could have severe repercussions on end-users putting their finances and private information at risk [3, 29, 33, 47]. Therefore, a body of research in the fields of Human-Computer Interaction (HCI) and Security aimed to understand the challenges encountered by developers in the rapidly evolving field of software development (see Section 2.1). To this end, the research community primarily focused on software developers from North America and Europe.

The studies around privacy and security have predominantly been influenced by Western liberal values, including the early work of Westin [68], and Warren and Brandeis [67], where a large body of prior studies examined the usable security issues in the Global North. However, the difference in culture and norms outside of Western countries demands a unique lens to understand the contextual privacy and security. Therefore, privacy and security studies are crucial for developing countries, where general privacy and security structures still need to be developed or are in the process of being developed [16, 36, 38, 56]. The recent literature also suggests that privacy and security are contextual, where we need a situated understanding to explore the design and policy practices (see Section 2.2). For instance, the culture, values, perceptions, and norms of software developers and their organizations in the Global South can influence security practices bringing forth unique local challenges. This article focuses on Bangladesh, a developing country in South Asia. A recent boom in digital technology use and software development fueled by the government’s initiatives of transforming the country into “Digital Bangladesh” [36, 38, 56] entailed our interest in understanding software security practices in Bangladesh.

Bangladesh is on a path to become a major source of technology outsourcing. The low-cost base and government incentives, including IT sector tax exemption, have catapulted it into the top 25 countries in the global outsourcing market [16]. Further, the software developed in Bangladesh is exported to more than 30 countries [16, 37]. While software development in Bangladesh has reached a global level, there rises the need to understand local software security practices. This lack of understanding could lead to potential security issues on a global level, pointing to the need of examining software security practices in Bangladesh [8, 44, 52]. Several studies [6, 7, 9, 10, 35, 62] conducted in Bangladesh demonstrated the importance of focusing more on the technology-users in developing countries. However, these studies [6, 7, 9, 10, 35, 62] have focused on end-users’ security behavior and cannot be directly translated to the domain of developer-centered security [50], further emphasizing the significance of investigating situated software security practices in Bangladesh.

To the best of our knowledge, our study is the first to explore security practices of software developers in the Global South, where we particularly focused on software industries in Bangladesh that export to Western countries. Our study positions itself in a transitional period when Bangladesh is becoming a large contributor to global software development via outsourcing, but little study has been conducted to understand local developers’ security perceptions and practices. To this end, we investigated the following research questions: RQ1. How do the developers in Bangladesh perceive security in the context of software development? RQ2. What factors influence software security practices in Bangladesh?

To address the above research questions, we conducted semi-structured interviews with 15 software developers in Bangladesh. Our findings unpack how the developers in Bangladesh view “security” in the process of software development (RQ1; see Section 4.2). Here, we reveal three sensemaking lenses on software security, including weighing the cost and benefit of implementing security (Section 4.2.1), protecting user data (Section 4.2.2), and preventing source code leakage (Section 4.2.3). We also shed light on factors that impact the security practices of developers in Bangladesh (RQ2; see Section 4.3 and Section 4.4), which include frequent changes in clients’ requirements (Section 4.3.2), top-down authority (Section 4.4.1), and long chain of command (Section 4.4.3).

Our findings lead to recommendations on how we could develop situated and sustainable strategies to help developers in Bangladesh incorporate security in the software development process. These strategies include establishing a common security ground through multi-institutional involvement, introducing situated cultures to accommodate cross-team and cross-country collaborations, and rethinking “change management” for better project management. Overall, our study contributes to advancing the HCI and Security community’s understanding of security practices in the software development landscape of Bangladesh.

2 Related Work

The developers build a software that end-users use; thus, the scopes of security considerations vary between a developer and end-users. For instance, end-users should be cautious about not using a software with security flaws, where developers need to pay attention in developing a software that does not have such flaws. In these contexts, the study of Pieczul et al. [50] identified the limitations of translating our understanding of end-users’ security behavior to the domain of developer-centered security, aiming to develop applications free of security vulnerabilities. Such limitations include our lack of understanding of the professional scenarios the developers find themselves in—impacted by organizational culture, professional requirements, and the availability of tools and support [50]. The findings from this study highlighted the importance of gaining an in-depth understanding of security practices in the evolving field of software development [50]. In this regard, the study of Acar et al. [4] outlined an agenda to understand the developer’s attitude and provided guidelines to support them by measuring the status quo and developing tools and interventions.

To this end, recruiting professional developers for studies was a challenge. Thus, a few studies [25, 42] looked into alternative options for participant recruitment, including Computer Science majors, GitHub users, and freelancers using deceptions; however, the findings from these studies confirm that the open recruitment (i.e., without using any deception) of developers from software organizations presents the viable method to investigate software security practices in professional settings [25, 42]. Despite the challenges in participant recruitment, several studies investigated the security practices in software development—we present the notable findings in Section 2.1. We found that none of these studies focused outside Western contexts where we situate our study. In Section 2.2, we highlight prior studies emphasizing the importance of understanding local security practices based on end-users’ security behavior, indicating that software developers’ security practices in the Global South could be situated in local contexts, warranting further investigation—the gap in existing literature we addressed in our work while Pieczul et al. [50] pointed to the limitations of translating end-users’ security behavior to the developer domain.

2.1 Security Practices in Software Development

The study of Caputo et al. [20] presents the findings from case studies exploring organizational attempts to develop secure software in a context where the design and engineering processes provide limited guidance; the authors pointed to the tension between the motivation of developers and the process of software development and how the software security practices correlate to developers’ risk perceptions and compliance requirements. In another study [40], Lopez et al. examined how the perceived responsibility of developers relates to their security-preserving actions, showing that their responsibility is limited by the collective practices of development teams and the organization as a whole.

The study of Assal and Chiasson [13] pointed to the lack of planning, organizational support, resources, and government regulations as why developers are not motivated to adopt security practices in software development. In a follow-up study [14], the authors identified the optimism bias of software developers believing that the applications they develop would not be a potential target of adversaries. The factors contributing to developers’ optimism bias include the inability to identify possible consequences and ambiguity about whether their effort spent on security would result in substantial value for them and their organizations [14]. In some cases, developers consider that it is the job of a security expert to fix the vulnerabilities in written code [14].

The study of Smith et al. [60] found that a lack of support for progress tracking and batch processing interferes with developers’ workflow, which could deter security practices in software development. Further, the lack of information on potential vulnerabilities makes it difficult for the developers to understand the risks associated with a security flaw in their code, where they expect to have severity and priority scores for security bugs and proper ranking of warnings [60]. In a separate study [21], Chalhoub et al. found a shortage of security experts in the design phase, and thus, security considerations in the design stage are ad hoc. As a result, security-sensitive features might be ignored if the developers do not identify them during implementation. The findings from this study also point to the lack of effective communication between different stakeholders within an organization, which creates internal tension and makes the security implementation further challenging for the developers [21].

The optimistic view towards secure software encourages the developers to adopt security tools during development [71]. However, the complexity of tools could deter developers from using them [61]. The findings from the study of Smith et al. [61] offered guidelines to systematically build tools that support developers’ information needs while analyzing details on vulnerabilities. Here, the authors considered different categories of information that developers might seek during code testing and analysis, including the types of vulnerabilities, potential attacks that could exploit them, and the available options to fix them. In another study [74], Xie et al. suggested building a plugin for Integrated Development Environment to alert developers to maintain secure programming practices. Further, a better design of the Application Programming Interface (API) is recommended to reduce the vulnerabilities in code [72].

A body of research [13, 45, 75] indicated that developers could not reliably build secure software due to the lack of knowledge. To advocate software security education, multiple studies [73, 75] pointed to the importance of security guidelines mandated by the industries, which would encourage academic institutions to incorporate software security as a part of their curriculum. The ethnographic study conducted by Tuladhar et al. [65] investigated how a software development team adopts security practices within their workflow. The authors found that the learning dynamics of a team contribute to the positive shift in developers’ security awareness, which motivates the developers to apply their security knowledge during coding. This process drives the establishment of secure coding practices and builds a secure development culture within an organization.

As discussed above, prior studies focused on software security practices in the Western contexts, where there is a dearth in understanding security practices in the software development practices in the Global South. We addressed this gap in our work, where we focused on Bangladesh. In the next section, we highlight the situated security and privacy practices of end-users outside of the Global North, further emphasizing on the gap in understanding the contextual security practices of software developers.

2.2 Situated Privacy and Security

Security and privacy are contextual and demand a situated understanding of users’ perceptions and behavior to explore the design and policy practices [24, 43, 48]. The findings from recent usable security studies [6, 10, 22] support this argument that local values often contrast with the liberal notions of privacy and security embedded in current computing systems. However, digital security research beyond Western contexts and a liberal framing is still at its very early stage [23, 66]. Below, we briefly discuss the notable usable security studies conducted outside Western contexts; while these findings focusing on end-users cannot be directly translated to the domain of developer-centered security, they point to the significance of understanding situated security practices of different user groups, including software developers.

While online threats are global, perceptions of threat are very localized [10, 22, 35, 39]. The study of Al-Ameen et al. [10] explored how the privacy perceptions of people relate to their effort to deal with the issues of urbanization and the opportunities that come with digitization in the Global South. The authors [10] examined how users balance their needs, conveniences, and privacy in the context of data collection and sharing by apps. The study of Haque et al. [35] presented how clientelization, reputation, and situated morality influence the security and privacy behavior of people in the digital service centers in Bangladesh. In another study [22], Chen et al. investigated the security and privacy practices of the people in urban Ghana while browsing the Internet. The study [22] shows that participants judge the trustworthiness of a website based on its appearance, where they reported confidence in being able to defend against cyberattacks despite passwords often being their only line of defense.

People’s cultural norms impact their sense of confidentiality and privacy. The study of Abokhodair et al. [1] examined how the youth in the Middle East conceptualize values such as privacy, intimacy, and freedom of expression in the context of social media, showing that the interpretation of privacy among participants goes beyond the concerns for security and safety. The study of Alghamdi et al. [11] investigated the privacy and security practices for household bank customers in Saudi Arabia. They found that trust and esteem placed in family and driving restrictions motivate female participants to share their banking information with male family members. While digital harassment is a growing concern in many developing countries [9, 44], the study of Sambasivan et al. [54] identified that the risks and fear of harassment prevented the women in urban India to provide their phone number for accessing public Wi-Fi services.

Digital devices like mobile phones designed for developing regions often fail to satisfy local needs. In a study conducted with low-literate Berber women in Morocco [27], the authors identified that lack of functional literacy and non-standard mobile phone interface, including a complex language environment, presented significant barriers to using mobile phones. The studies by Ahmed et al. [7] and Sambasivan et al. [53] demonstrate that mobile phones often do not have a one-to-one mapping with a user in the resource-constrained settings of developing countries. Thus, the strict privacy requirements in digital technology could disrupt the relationships with friends and family members [7, 53]. In a separate study with women in Global South [52], the authors explored the privacy negotiation of female users from their family members while using a mobile phone.

The overall findings from these studies indicate that the misconceptions about local culture may result in inappropriate threat modeling, where there is a dearth of existing literature to understand the software security practices outside of Western contexts. We started to address this gap in our work and unveiled the software security practices in Bangladesh, representing a booming software industry in the Global South.

3 Methodology

We conducted semi-structured interviews with 15 participants between January and May 2021. In preparing the questionnaire for the interview, the research team discussed and iterated on questions. We also gathered feedback from the colleagues at our labs, leading us to improve the structure and clarity of the questionnaire. The study was approved by Institutional Review Board (IRB) at our university.

3.1 Participant Recruitment

We contacted participants through email listservs and social media groups of alumni organizations from multiple universities in Bangladesh. We also shared recruitment messages on our social media profiles with “public setting”; re-shared by many others. We used snowball sampling, recruiting several participants from the recommendation of participants who had participated in this study. Anyone above 18 years, who was employed in a software development organization in Bangladesh at the time of our study and engaged in software development as a part of their professional responsibility, could take part in our study. We did not exclude any developers based on the type of software they develop. While it is challenging to recruit software developers for user studies [25, 42], we recruited as many participants as we could. The number of participants in our study (15) is reasonable as compared to similar studies with software developers [12, 13, 63, 64, 70, 75].

3.2 Procedure

We interviewed the participants over online communication platforms of their preference (e.g., Zoom, Skype). We conducted interviews in Bengali—the official language of Bangladesh. During the interview, participants responded to questions on the software development projects they worked on and their workflow, communication, and collaboration methods in the software development process. We asked them about their perceptions of security in software development and their practices and experiences in considering security factors during development. They also reported the challenges they encountered in using secure strategies during software development and their workaround to handle those issues. The interview questions used in our study are available in Appendix A. At the end, participants responded to a set of demographic questionnaires. We audio-recorded the interviews. On average, each session took between 45 and 60 minutes.

3.3 Analysis

Upon transcribing the audio recordings of interviews, the researchers who are native speakers of Bengali translated the transcriptions into English. We then performed thematic analysis on our transcriptions [18, 19, 28, 49, 58]. Two researchers independently read through the transcripts of half of the interviews, developed codes, compared them, and then iterated again with more interviews until we had developed a consistent codebook. Once the codebook was finalized, two researchers divided and coded the remaining interviews. After all the interviews had been coded, both researchers spot-checked the other’s coded transcripts and did not find any inconsistencies. Finally, we organized and taxonomized our codes into higher-level categories. A sample of the codes from the analysis process is available in Table 3 in Appendix C.

Table 1.

ID	Gender	Age	Experience (Years)	Academic Background	Area of Expertise
P1	Male	25–29	3–5	Bachelor’s Degree	Backend
P2	Male	25–29	3–5	Master’s Degree	Full Stack
P3	Male	30–34	5–10	Master’s Degree	Backend
P4	Male	25–29	5–10	Master’s Degree	Backend
P5	Male	30–34	5–10	Bachelor’s Degree	Backend
P6	Male	25–29	5–10	Bachelor’s Degree	Backend
P7	Female	25–29	1–3	Bachelor’s Degree	Frontend
P8	Male	25–29	1–3	Master’s Degree	Frontend
P9	Male	25–29	1–3	Master’s Degree	Frontend
P10	Male	25–29	1–3	Bachelor’s Degree	Backend
P11	Male	25–29	1–3	Bachelor’s Degree	Backend
P12	Male	25–29	3–5	Master’s Degree	Backend
P13	Female	30–34	10+	Master’s Degree	Full Stack
P14	Male	30–34	10+	Master’s Degree	Full Stack
P15	Male	30–34	10+	Master’s Degree	Full Stack

Table 1. Demographics of Participants

3.4 Demographics of Participants

Table 1 presents the demographic information of our participants. Among the 15 participants in our study, 13 are men, and 2 are women. Their age varied between 25 and 34. All our participants hold university degrees and are currently employed in software development. Twelve participants (P1–P12) were software developers, and their years of experience varied between 1 and 10. Three participants (P13–P15) reported playing the team lead role in their organization and had more than 10 years of experience in software development. In a software company in Bangladesh, a project team consists of developers and a team lead. Here, software developers assume the role of developing and testing the software. A team lead can directly participate in software development while also carrying out project management.

3.4.1 Experiences in Software Development.

Our participants reported following a waterfall model or the variations of Agile. They mentioned different types of projects they worked on, including Web, desktop, and mobile applications for social networking, banking, investor tools, information management (e.g., Central Message Handler), cloud infrastructure setup, e-commerce, and support utilities.² Each participant in our study was experienced with using multiple programming languages (e.g., Python, JavaScript, C, C++, Java, PHP). Their expertise varied between backend, frontend, and full stack development (see Table 1). Almost all of our participants mentioned having no formal training on security practices in software development, which is similar to the security training experience of developers reported in prior studies [4, 13, 34, 45, 69].

3.4.2 Participants’ Organization.

All of our participants reported working in medium (at least 100 employees) to large (at least 500 employees) companies.³ The companies our participants belong to select the software development projects for their employees based on the requirements of their clients in the USA, Australia, Saudi Arabia, and Europe (e.g., Germany, United Kingdom), which are delivered to the clients at the end of development. We recruited one participant from each company. That means our data contains information from 15 developers in 15 different companies situated in Bangladesh; none of these companies represent a local branch of an organization outside of Bangladesh.

4 Results

In this section, we followed the guideline from prior work [5, 49, 55, 58] to report the results of our qualitative study in a consistent manner, where we employ the following terminology based on the frequency of comments in participant responses: a few (0–10%), several (10%–25%), some (25%–40%), about half (40%–60%), most (60%–80%), and almost all (80%–100%). Table 2 in Appendix B presents a summary of the prevalence of themes reported in this section.

4.1 Security Considerations within the Software Development Stages in Bangladesh

Our findings indicate that software development stages commonly used in North America [13] might need adjustments to accommodate local norms and practices in Global South. To this end, our analysis unpacks the software development stages in Bangladesh, as portrayed in Figure 1. In the design stage of software development, implementation is conceptualized and design decisions are taken. Including developers in this stage helps the software development process and grounds the timeline and complexity of the projects. However, our participants reported that software developers do not get an opportunity to participate when design decisions are made by the clients and higher management in their company (see Section 4.4.1). Based on the outcome of this stage, the implementation tasks are allocated to the developers with fixed deadlines without any input from them.

Fig. 1.

In the implementation stage, the coding of the product takes place. Here, our findings unveil two challenging scenarios: (1) where security is not even considered in the client’s requirements (see Section 4.3.1) and (2) where security is considered in the client’s requirements but is marred by challenges of changes and collaborations (see Section 4.3.2). During implementation, our participants point towards cross-team collaborations, where the client divides a project into multiple segments and distributes it across development teams from different organizations. Such collaborations and distribution of work add to the challenges that our participants encounter during development, along with the frequent changes in clients’ requirements (see Section 4.3.2).

In the developer testing stage, testing is performed by the developer; in the code analysis stage, code is analyzed using automated tools; and in the code review stage, code is examined by an entity other than the developer. Our participants do not view the developer testing, code analysis, and code review as individually necessary stages but as possible options to select one for identifying bugs in their code. Most of them reported leveraging developer testing, where several participants mentioned using code analysis. A few participants mentioned exploiting code review, where the lack of workforce and tight deadlines constrain the developers’ scope for code review.

The primary focus of our participants during testing is to identify functional and user interface (UI)-related bugs, where security is a secondary consideration. Even when a security bug is found, almost all participants reported going through a chain of communication for guidance on whether and how to address this issue (see Sections 4.2.1 and 4.4.3). In the Post-development Testing stage, testing and analysis processes occur after the developer has committed their code; none of our participants referred to post-development testing as a part of their software development life cycle.

4.2 Sensemaking Lenses on Software Security

Following our discussion on the lack of security considerations in the software development stages (see Section 4.1), in this section, we dive deep into understanding how software security is perceived by the developers; more broadly, software development organizations in Bangladesh.

4.2.1 Weighing Cost and Benefit.

Some participants reported how they weigh the cost and time of testing code for potential bugs against the benefit they aim to attain through this process. Their perceptions of benefit indicate providing features and functionalities the clients requested, where how they deal with a security bug if identified is measured in terms of the additional cost. For instance, P1 reported, “It totally depends on features that the clients ask for. For Security and other implementations, if there needs risk analysis, we might think of designers, bug fixers, they might need training. If a feature has security, then we think about it. Otherwise not.”

Driven by Features and Functionalities. Several participants reported that their teams perform code analysis by examining various test cases, where their primary objective is to validate the written code for specific features and functionalities. For example, P1 mentioned conducting feature testing to check and ensure consistency in the application data flow. In another instance, P4 reported, “The static analysis tools we use usually read the newly written code and provide outputs, like the name of the variables is not industry-standard, using for loop twice which is not necessary, and function is not used properly.”

We found instances where the participants reported using tools to identify functional and UI-related bugs; P8 mentioned, “Our team gives input on every page to check for any errors. Then, stress UI/UX to find if this is giving any crash or not... We prefer the Black box testing method, which is acting as a user to find UI bug, or maybe a functional bug.” A few participants also referred to load testing, where P8 said, “We use application named Jmeter to check how much traffic the software can handle.”

Security Bug: “Is it critical?”. Almost all of our participants mentioned that if they identify a security bug in their code, they first reach out to their team lead, asking for their guidance on how to address the issue. Then, in consultation with the client, the software company asks the developers to take the necessary steps. The client and the higher management in software organization speculate the risks associated with a security bug and consider the time it would take to fix it. Upon considering the product delivery deadline and the criticality of the security bug, software developers might be asked to ignore that bug. One of our participants (P6) said, “If a security bug is identified when the deadline is nearby and if it requires a long time to fix, the client decides based on the criticality. If it [bug] is critical, then it goes to the backlog, and if the bug is normal [speculated risk is low], then he [client] asks to release it [product; without fixing bug]. We [software developers] do not usually have any say on this.”

How the client and higher management in a software organization speculate the risk associated with a security bug might lack transparency and appropriate metrics. In one instance, a six-digit CAPTCHA was only working for a five-digit input; however, the software developers working on that project were asked to ignore this flaw and proceed with the delivery of the product. Our participant, P2, reported that his company’s action on fixing a security bug (if identified) directly relates to how they view the impact of not fixing that bug on the product’s overall success.

4.2.2 User Data Protection.

Some participants view software security as a means of protecting user privacy. While software companies deal with user data, P1 reflected on the care these organizations should take in the process; he said, “What I think about software security is that data is very valuable. It is valuable when it goes to a third party. They can do good business with that data or harm us with it. So, we [software organizations] should ensure that it [user data] is protected.”

As we asked participants about their software security strategies, a few referred to their policy of encrypting user data while storing it in the server. Here, the sensitivity of user data motivated their companies to deploy encryption protocols. For instance, one of our participants (P10) worked on a project for a healthcare organization that would store and maintain sensitive information of marginalized groups and, thus, needed encryption to secure users’ health data. Another participant, P11, worked on developing a banking application. He shared his view of the significance of protecting users’ financial information. Although he did not mention any software security strategy taken during the development phase, he reported that his company has mechanisms to check and ensure the integrity of data communicated over the Internet.

These participants reported that they are not responsible for deploying such security protocols (e.g., encryption). Instead, the higher management at their organization takes care of that. We noticed a lack of understanding among our participants about how encrypting user data or network-level security protocols work in sync with the software they develop, where P6 pointed out that the lack of collaboration between the management and software developers leaves them with a blur in understanding these security mechanisms.

4.2.3 Preventing Source Code Theft.

Most participants reported concerns about the theft of programming code they write in software development, where they mentioned taking steps to protect their source code. For instance, P2 said, “As we have competition, there are risks posed by intruders from other companies. [To protect against them], we use servers with secure firewalls, antivirus as endpoint security, and paid third-party software to detect threats.” Our participants also discussed the steps they take in terms of access control and management to prevent source code theft by competitors.

Outsider Threat Control. Several participants mentioned privileged access implementation for a group of IP addresses to isolate the development environment from outside threats. In this context, P2 reported that only the IP addresses from their office would have access to the source code repository. Another participant (P1) stated that his company mandates VPN authentication to restrict unexpected users; he said, “For proper authentication, we use VPN, and we keep source code in a private repository [maintained by his company] instead of using third-party storage services.” The participant further added, “When we use pull, push in the code, our company mandates to use their own VPN. Since now it has been working from home, therefore, we can not modify source code without using company VPN. And during our usual in house work, we used to work on a desktop which was password protected from administration.”

One participant, P8, further emphasized using secure VPN authentication while working from home: “For remote working, we must get connected to the VPN provided by my office. We cannot connect remotely through any random PC.” A few participants mentioned using a one-time password (OTP), certificate validation, and a JWT token for secure authentication to their code repository.

Insider Access Management. In addition to tackling vulnerabilities posed by intruders from outside an organization, the honesty and integrity of employees are crucial to prevent source code leakage. One of our participants (P13) shared the experience of source code leakage through a former employee at her company; she reported, “Our [software] developer has left the company, and they took our code base and the client-list [without authorization]. It is like, company A was developing software for the client but the developer of company A left without giving any notice and took the code base as well. Later, he joined company B and used the stolen code for that company.”

In these contexts, most participants mentioned the use of role-based access control to software development resources, where the employee’s needs and their position in the hierarchy of an organization are taken into account. We found that software companies maintain caution in sharing source code with a new employee and only share a part of the code base that the employee would need. To illustrate the strategy, P1 explained, “When a new employee joins the team, we give them a part of the source code and some guidelines for working on it. In the meantime, we create branches in code to avoid conflict as we will merge.”

Cyber Hygiene. Among the participants who discussed access control as mentioned above, most believe that additional measures are unnecessary for software security. A few of them shared their perceptions that Cyber hygiene further contributes to securing their workspace from outsider threats. They referred to the guidelines from their employers for secure Web browsing to avoid computer malware and online scams; P7 stated, “Our [development] environment is secure enough. We do not need to have any other security measures in mind; just a few more things we consider when we visit different websites, like, we should not click on a link unnecessarily.”

One of our participants (P3) reported satisfaction with the device authentication that he believes adds to the measures they take in the context of software security, as he said, “On top of that [access control and version management], my working laptop is secure with password—so, a lock is there, and no one can access. So, we have a low risk of security vulnerabilities.”

4.3 Security Practices: Role of Clients

As we looked into how software security was handled in Bangladesh, we observed that the decision to implement security features largely depends on client requirements. Here, P8 commented, “If they [clients] are not bothered by it, then why should we? We just simply do as we are told, following [client’s requirement] the best we can.” Several participants indicated that they do not receive any monetary benefit for identifying a security bug or deploying a security feature unless the clients explicitly ask that as a part of their project requirement. Thus, they do not perceive security as adding value to their performance or the company’s reputation. One of our participants (P3) stated, “There is not like that something must be done with security... If security is not adding monetary value to us, then we are not doing anything extra.” Therefore, in this section, we look beyond how security is handled during software development and focus on understanding the impact of client requirements on security practices.

4.3.1 Security Is Not a Part of Client’s Requirements.

First, we look deeper into the scenario where security is not included in the client’s requirements. Most participants indicated that clients typically do not ask for security as a part of their requirements. However, a few participants attempted to convince their clients to allow additional time and budget for implementing security protocol, such as access control to server that they considered necessary for secure functioning of the product. These participants reported their frustration during the interview with us, as they could not convince the clients in these scenarios, where they pointed to the knowledge gap and the client’s damage control strategy.

Knowledge Gaps. One of our participants (P1) shared his experience when he failed to make the client realize the importance of access control implementation on their product: “I worked in an iterative application improvement project for a client. Even though I gave them all the documents about the server, the importance of an access control layer, and the consequences of avoiding it, the client did not consider those security requirements. He did not think it was necessary.” A few participants wanted to incorporate secure cloud storage into their developed product. However, they had to set aside the plan, as their clients did not agree to allocate the necessary resources for implementation.

Damage Control. One participant, P7, referred to the damage control strategy of clients, where they do not typically consider security as a part of project planning. Rather, after the final product is released, clients get back to the software developers to fix bugs if an unexpected incident happens concerning security. The comment from P11 echoes P7’s perspective on the client’s strategy: “Until the end users are affected by any security incidents, they [clients] do not care much about security. Security comes when something has happened.”

4.3.2 Security Is a Part of Client’s Requirements.

As we look at the scenario where security is included in the client’s requirements—mentioned by some of our participants—almost all of them reported that security is perceived as a secondary component in software development. A few of these participants worked on application development for the banking sector and e-commerce, where the clients specified some security requirements (e.g., access control in the database, HTTPs proxy server). These participants shared with us the challenges they had encountered in deploying security schemes due to the delay caused by frequent changes in clients’ requirements and varying time zones. As they mentioned, when the project timeline is delayed, functional implementations become a sheer focus, even at the cost of ignoring security requirements. Moreover, such challenges are not limited to security implementation only but also extend to the overall scope of their project.

Frequent Changes in Requirements. As pointed out by our participants, their clients often fail to maintain consistency in their requirements, where they keep updating the product design throughout the software development process, making it difficult for developers to cope with the changes in workflow. One of our participants (P13) said, “These [frequent changes in clients’ requirements] are very common. A client approved a design, and after taking the approval, we started working on it. All of a sudden, the client changed his mind and said, ‘Who approved the design? It does not look good.”’ Another participant (P15) expressed his frustration that, in some cases, clients change their preferences at a point when the development team has already deployed substantial resources and completed one-third of the project.

Varying Time Zones. Our participants reported that they need to hold meetings with the software development teams from different countries, where the client divides a project into several segments and distributes it across multiple teams. For these meetings with the teams situated in varying time zones, developers in Bangladesh have to conform to the time set by the upper management at their company. While little to no say in scheduling meetings could affect the work-life balance of software developers, the physical struggle to keep awake at midnight leads to communication gaps, as mentioned by our participants. For instance, P6 stated, “When two teams are in two countries...we needed to stay awake at midnight for that. Due to this struggle, we did not realize the scope of the whole project and the extent of our responsibility within the project.”

4.4 Security Practices: Role of Organizational Culture and Leaderships

Following our discussion on the role of clients in the previous section, we now shed light on the role of software development organizations that substantially impact developers’ security practices in Bangladesh.

We observed that almost all participants reflected on their company culture, which dictates security practice as the responsibility of clients and the higher management. One of our participants (P1) reported, “We [software developers] do not follow any default security standards. What we do is, management will give us a project-by-project guideline, and we will work on that...These securities are handled by our CEO himself. If any security issue occurred [after product release], then they [clients] report to our CEO.” As this participant elaborated, their organization’s Human Resources (HR) department communicates with the client to understand their requirements. Then, the higher management decides whether and how they could fulfill those requirements based on the availability of time and resources.

In cases where the client and management consider security, we found multiple challenges, including top-down authority, discord in teams, and a long chain of command. These challenges hinder the participants’ efforts in identifying and addressing security issues that hurt their progress toward the project deadline. Further, these challenges cause delays in a project, and therefore, lead development teams to ignore security testing and focus on project completion by the deadline. For instance, P5 mentioned, “Sometimes we love to do it, but time doesn’t allow us to test for every method and function. Due to time, we can’t do unit test for every method and function. We just work to satisfy the quality of the product and sometimes we just complete the project by deadlines. We have limited resources, and deadlines are important.”

4.4.1 Top-down Authority.

Our participants referred to two prime aspects of top-down authority in decision-making. First, software developers are not included in the discussion loop when the clients and higher management in their company set the project goals and timeline, or when the client demands a change in the middle of a project. Due to such polarization in decision-making, a gap emerges between the time for project completion estimated by the client and higher management and the time it takes for the developers to meet the deadline. Most participants reported that the workaround of the client and management to handle this gap is to cut off security-related implementations. For instance, P8 referred to an incident where the client instructed developers and higher management in his company to ignore a security flaw (a six-digit CAPTCHA was only working for a five-digit input) to deliver the product on time.

Second, there is a limited scope to open a dialogue from the developer’s end to readjust the project timeline when a security bug is identified and needs to be fixed. A few participants even feared losing jobs if they failed to meet the product delivery deadline. One participant, P5, said, “Deadlines play a big impact in development...sometimes, developers lose jobs for not meeting deadlines from time to time.” Thus, our participants do not feel motivated to identify and address the security vulnerabilities in their code. Instead, they view security as a roadblock to meeting their deadlines. One of our participants (P2) reported, “From a developer’s perspective, we kind of do not care about security. In general, security always slows down the [software] release process. We [developers] just work to satisfy the quality of the product; we just complete the project by deadlines.”

4.4.2 Discord in Teams.

About half of our participants pointed to the polarized power exercised by the teams from other countries, leading to challenges in cross-country collaborations. One of our participants (P10) reported that in a cross-country collaboration, developers in his company would not have any say on the task allocation and management, where he further added, “Different teams work in different ways and it becomes difficult to find a middle ground—it delays the security implementation.” In the context of authorization and authentication, P1 explained, “Source code level security is handled by the developer in the other team by OAuth/OAuth2. We do not know much about how those processes work.” These insights from participants indicate the lack of communication between cross-country teams, contributing to the gap in developers’ understanding on how security requirements are handled in their collaborative workflow.

4.4.3 Long Chain of Command.

Almost all of our participants mentioned that if a security bug is identified in their code, then they have to go through a long chain of command to get instructions and guidelines on how to address that issue. In such situations, developers are not authorized to deviate from the workflow specified by the client and the higher management in their company. To this end, some participants referred to the delay incurred at the client end during decision making, where P13 commented, “...The projects get lengthy; decision lag is created, and even at times, five-line content approval takes 15 days [at the client’s end]. We need to go through a long process... For any decision, a client representative [who communicates with the HR and higher management of a software company in Bangladesh] has to depend on a senior executive, and his senior waits for his CEO’s quote. Who takes which decision in this long chain remains very unclear to us during software development.”

4.4.4 Lack of Training.

Most participants reported joining the software development company without any training on software security, where P4 said, “I really did not have any knowledge about security during my academic period. With zero knowledge, I joined an office [software company].” A few participants mentioned gaining basic knowledge on security during their academic preparation but failed to leverage that in professional settings; P5 commented, “Academia helped me learn the fundamentals... However, academic lectures need to accommodate adequate hands-on experiments, aligned with the needs of [software] industry.”

Almost all participants pointed to the lack of security training in their company; one of them (P8) commented, “My company taught me nothing. Here you have to learn everything by yourselves or from senior colleagues.” While a few participants mentioned that their companies arrange software security training, they noted that those training sessions are not offered regularly. For instance, P9 reported that he did not receive any training when he joined his company. However, they later trained with a group of new employees. In these contexts, most of our participants reported ad hoc security learning from their team members, where P1 described how he learned about implementing “access control”: “When I got into issues with the code [for access control] on GitHub, I asked experienced colleagues during the team meeting. They gave suggestions and shared their experiences.” Our participants also reported using YouTube tutorials and the websites they found through Google search (e.g., stackoverflow.com) as familiar sources of learning about software security.

5 Discussion

In this section, we first highlight several situated contexts in the software development process in Bangladesh, where we also present the similarities with the Western contexts as reflected in our findings. We then provide recommendations to improve the situated software security practices in Bangladesh (see Figure 2). We conclude the section with a discussion on the limitations of this study, offering guidelines for future research in these directions.

Fig. 2.

5.1 Situated Software Security Practices

Although online threats are global, perceptions of threat are very localized [10, 22, 35, 39]. Therefore, understanding software security practices in localized contexts is essential. In this regard, our findings unpack the challenges of adopting software security practices in Bangladesh, which include functional prioritization over security, top-down authority, long chain of command, knowledge and training gaps, frequent changes in requirements, and varying time zones. We observed optimism bias among developers that security would be taken into consideration at some stages in software development, although they were not particularly aware of the process. The optimism bias is common among end-users, too, where they see security risk as a distant harm due to their past experience with technology use [26, 76]. We found that the lack of communication between developers at different stages of development leads to the opacity in their understanding on how security is handled, and so on, the optimism bias in this respect.

Our study shows that unlike software development process in North America [13], developers in Bangladesh do not view the developer testing, code analysis, and code review as individually necessary stages, rather as possible options to select one from. However, each of these stages serves a different purpose in the software development life cycle, and thus, leaving one or multiple of them out of the development process could lead to security vulnerabilities [13].

We identified collaboration challenges with cross-country teams, unique to Bangladesh as compared to the prior studies conducted in Western contexts [13, 14, 45, 75]. The polarized power exercised by the teams from other countries bring challenges for the developers in Bangladesh in terms of control and management in cross-team collaborations, which is further aggravated, as the developers typically do not have voice on the decision related to work assignment and frequent changes by the clients (see Section 4.4.1). The cross-country collaborations also bring coordination issues due to varying time zones (see Section 4.3.2). Such challenges lead to delays in product development, making it difficult to follow security practices where functionality is often prioritized over security while meeting the deadline.

In light of our findings, we observed a few similarities with the Western context as well. Our participants reported the lack of software security training in both academic and professional settings, echoing the findings from prior studies [13, 45, 75]. Similar to the Western context [13, 20, 21, 40], we found that the lack of planning and organizational support demotivates developers to adopt software security practices in Bangladesh (see Section 4.4). The lack of organizational motivation in providing security training to developers in Bangladesh could relate to client’s focus on damage control (e.g., fixing bugs only when security incident arise) instead of security implementation during development (see Section 4.3.1).

5.2 Security Practices in Situated Contexts

5.2.1 Open Communication with Clients.

While convincing clients to include security can be challenging, as depicted in our findings (see Section 4.3.1), the software development organization should proactively plan and translate the technical specifications into user-friendly descriptions. Such planning can include simplifying the technical jargon, using appropriate rhetoric, and providing data that the clients could easily understand. For instance, providing statistics on source code leakage and outsider/insider threats that can jeopardize a project could encourage clients to pay more attention on access control requirements. Although taking such steps at software development organization’s end is not common—reflected in our findings—the security success following such strategies could be eye-opening for the overall software industry in Bangladesh.

5.2.2 Command Chain Bypass.

Our findings suggest that the long chain of command causes delays and hassles in the software development process (see Section 4.4.3). We believe the communication and decision channel could be augmented by creating bypass pathways to handle the security issues in an efficient manner. For instance, when a security bug is identified in code, it may not need to be approved through all the entities in command chain, rather be left at the discretion of software developers and their team lead to take timely and appropriate decision around security protection. Towards the success of this strategy, we identified the need of organizational support for developers in the form of training on security practices during software development, along with persuading them to learn and follow new security practices that would not only contribute to their self-growth but also benefit the organization as a whole.

5.2.3 Project-customized Hours.

Our study points to the challenges of developers in Bangladesh in cross-country collaboration due to varying time zones (see Section 4.3.2), which not only could delay the decision-making process but also frustrate the developers when they need to frequently work outside of their working hours to accommodate the needs of their clients and collaborating teams (see Section 4.3.2). In such cases, project-customized office hours could help the development teams within an organization to create their unique subculture and organize meetings with the out-of-country clients within their situated working hours, leading to function as a solid collaborative unit including developers and the clients.

5.2.4 Multi-lane Development Pathways.

Our findings show that the focus on functional requirements and the challenges of addressing those by the deadline are substantial deterrents to software security practices (see Section 4.3.1). Introducing dedicated and parallel pathways for security and functional implementations could help to address such issues. We note that this approach might not be ideal for the traditional waterfall software development models, which most of our participants reported being used in their organization. However, the software development life cycle has seen significant improvements over the years with the introduction of iterative and agile development plans, letting the organizations create multiple lanes of development [2]. This further mitigates the risks of ignoring security implementations when the functional requirements increase during development.

5.2.5 Rethinking “Change Management”.

Change Management in software development refers to the transition from an existing state of the product to a new state.⁴ Almost all participants reported the difficulties created due to the frequent changes in the project requirements (see Section 4.3.2). We suggest leveraging adaptive contractual agreements and maintaining proper documentation to address such issues.

While software development organizations create contractual agreements with their clients based on the project’s initial requirements, the contract should include scopes of possible changes during the development process. Such agreements could specify the categorization of possible changes based on the extent of additional work, cost, and time requirements, along with a clear plan and guideline on how the clients and developers would collaboratively handle these changes. Such an approach would minimize unexpected delays by letting software developers address the client-specified changes in an organized manner and without compromising security requirements. However, we acknowledge that such a system needs to be studied and validated in future research before implementation.

Our findings present cases of the clients being forgetful of the approved changes and later questioning those changes upon implementation by the developers (see Section 4.3.2). Thus, the changes in the initial requirements and designs must be appropriately documented along with the authorizations for each change. While a change in requirement, including the one concerning security, could add to the project’s cost, such documentation would ensure the proper reflection of that to the clients and the procurement of necessary payment for accommodating those changes.

5.3 Limitations and Future Work

We interviewed 15 participants in our study with software developers. Although our sample size is relatively small, we believe that it is reasonable as compared to the prior studies with developers [12, 13, 63, 64, 70, 75]. Here, we followed the widely used methods for qualitative research [15, 17, 18, 19, 59], focusing in depth on a small number of participants. We acknowledge the limitations of such a study that a different set of samples might yield varying results. Thus, we do not draw any quantitative, generalizable conclusion from our studies. We would conduct a large-scale online survey with software developers in developing countries in our future work.

We did not have a uniform distribution regarding the participant’s gender and age; all our participants were in the age range between 25 and 34, and two of them identified as female. It could be because most software developers are male⁵ and young.⁶ Further studies are required to understand the relationship between demographics and security practices in the context of software development.

In this study, we examined the software security practices in Bangladesh from the developers’ perspective. In our future work, we would investigate through the lens of higher management and clients to identify how all these stakeholders can work together to support software security practices in Bangladesh. Our findings shed light on the lack of academic preparation in software security; more studies are required on the educational institutions in Bangladesh to identify the opportunities and challenges in mitigating this gap.

Footnotes

https://www.crowdstrike.com/cybersecurity-101/security-it-operations/software-security/

For this classification, we considered our participants’ self-reported data and used Forward and Lethbridge’s [32] software taxonomy.

https://www.cipe.org/resources/small-and-medium-enterprises-in-bangladesh-an-assessment-report/

⁴

https://www.geeksforgeeks.org/change-management-in-software-engineering

⁵

As of 2021, 91.7% of software developers identified as male (https://www.statista.com/statistics/1126823/worldwide-developer-gender/).

⁶

The average age of software developers is under 30 (https://www.techrepublic.com/article/no-place-for-the-old-is-software-development-a-young-persons-game/).

A Interview Questionnaire

A.1 Question 1

As we know, a project may consist of teams of developers, testers, and others during the entire SDLC. Smaller companies may have only one project team, while bigger companies may have different project teams for different projects.

(1)

So what types of software development projects have you recently worked on? It can be web applications and services, mobile application, embedded software. Can you explain about your team that you work on [this question is for nudging to get more info]?

(2)

During the software development, what types of responsibilities/roles do you usually perform? It can be the role of front end developer, backend. REST API devops, Data scraper/ Analysis engineer, Full stack engineer.

(3)

Well, exactly which stage of development best defines your work based on the entire software development life cycle? For example, SDLC is divided into different stages of development: Design, Implementation, Developer testing, Code analysis, Code review, Post-Development.

A.2 Question 2

(1)

Would you tell us how you collaborate with yours and other teams within your organization during a software development?

(2)

Please tell us about an incident when this collaboration did not go/work as you expected.

(a)

Please tell us how you felt about that incident.

(b)

What do you do differently now, to avoid such an incident?

(c)

How is that working? (i.e., is participant’s [new] behavior helping to prevent similar incident from happening?) [If participant’s response denotes that it’s not working as expected]:

(i)

Please tell us what you expect from your colleagues and organization to avoid such incidents from happening in the future.

A.3 Question 3

(1)

During your tasks in software development, what types of security related practices are you familiar with?

(2)

How do you handle security issues when working on certain topics? Do you usually look for security-related guidelines or handbooks?

(3)

Can you share an experience where you had to solve a security issue? And what were the steps that you had taken?

(4)

Are there any mandatory security issues that you/your team usually take into account during software development?

A.4 Question 4

Well, let’s talk about some other factors in the software development life cycle that you/your team take into consideration during the entire cycle.

(1)

What are some factors that your team considers during the development life cycle? Can you prioritize those factors? (for example, deadline, cost, resources)

(2)

How does security fit in your/your team’s priorities?

(3)

Do your priorities change about factors when a deadline approaches? How?

(4)

Can you explain about certain security policies that your team has?

A.5 Question 5

Let’s talk about some current practices of your team

(1)

Are there any obligations by your employer/team for performing security testing that you know? For example, Test driven development.

(2)

What types of methods/tools are you/your employer currently using to ensure the security of applications? For example, Testing load test, black box, white box?

(3)

Do you perform testing on your (or someone else’s) applications/code?

(4)

Can you share your experience on performing code reviews/testing?

A.6 Question 6

(1)

Can you explain a situation or scenario when you communicate with a client about security requirements?

(2)

Can you explain one of your experiences of software security during the development life cycle? Let’s talk about your background in software security.

(3)

How do your employers support you in learning software security practices?

B Prevalence of Themes

Table 2.

Theme	Subthemes	Categories	Prevalence
Sensemaking Lenses on Software Security	Weighing Cost and Benefit	Driven by Features and Functionalities	10%–25%
	Weighing Cost and Benefit	Criticality of Security Bugs	25%–40%
	User Data Protection	–	25%–40%
	Preventing Source Code Theft	Outsider Threat Control	10%–25%
		Insider Access Management	60%–80%
		Cyber Hygiene	0–10%
Role of Clients	Security is not Part of Client’s Requirements	Knowledge Gaps	25%–40%
	Security is not Part of Client’s Requirements	Damage Control	10%–25%
	Security is Part of Client’s Requirements	Frequent Changes in Requirements	25%–40%
	Security is Part of Client’s Requirements	Varying Time Zones	25%–40%
Role of Organizational Culture and Leaderships	Top-down Authority	–	60%–80%
	Discord in Teams	–	40%–60%
	Long Chain of Command	–	60%–80%
	Lack of Training	–	80%–100%

Table 2. Prevalence of Themes among Participants

The column “Prevalence” represents the range of participants who reported the corresponding theme.

C Sample Code

Table 3.

Theme	Subthemes	Categories	Codes
Sensemaking Lenses on Software Security	Weighing Cost and Benefit	Driven by Features and Functionalities	Dependent on features requested by clients
			Feature needs security
			Feature and functionality validation
			Functionality bug detection
		Criticality of Security Bugs	Tension between risk from bugs and time to handle it
			Deadline impacts security decisions
			Controlled by client and upper management
	User Data Protection	Importance of User Data Protection	Security is a means of protecting user data
		Importance of User Data Protection	User data is valuable and sensitive
		Deployment of Data Protection Strategies	Data protection strategies deployed by higher management
		Deployment of Data Protection Strategies	Lack of understanding of developers on working of data protection strategies
	Preventing Source Code Theft	Outsider Threat Control	IP address-based access from the office
			VPN authentication to servers
			Token-based authentication
		Insider Access Management	Theft of code and client base by employees
			Role-based access to resources
			Caution with code access to new employees
		Cyber Hygiene	Secure web browsing
		Cyber Hygiene	Device authentication/Password protected devices

Table 3. A Sample of the Codes Generated from Our Analysis

These codes represent the themes presented in Section 4.2.

References

[1]

Norah Abokhodair and Sarah Vieweg. 2016. Privacy & social media in the context of the Arab Gulf. In Proceedings of the ACM Conference on Designing Interactive Systems (DIS’16). Association for Computing Machinery, New York, NY, 672–683. DOI:

Abstract

1 Introduction

2 Related Work

2.1 Security Practices in Software Development

2.2 Situated Privacy and Security

3 Methodology

3.1 Participant Recruitment

3.2 Procedure

3.3 Analysis

3.4 Demographics of Participants

3.4.1 Experiences in Software Development.

3.4.2 Participants’ Organization.

4 Results

4.1 Security Considerations within the Software Development Stages in Bangladesh

4.2 Sensemaking Lenses on Software Security

4.2.1 Weighing Cost and Benefit.

4.2.2 User Data Protection.

4.2.3 Preventing Source Code Theft.

4.3 Security Practices: Role of Clients

4.3.1 Security Is Not a Part of Client’s Requirements.

4.3.2 Security Is a Part of Client’s Requirements.

4.4 Security Practices: Role of Organizational Culture and Leaderships

4.4.1 Top-down Authority.

4.4.2 Discord in Teams.

4.4.3 Long Chain of Command.

4.4.4 Lack of Training.

5 Discussion

5.1 Situated Software Security Practices

5.2 Security Practices in Situated Contexts

5.2.1 Open Communication with Clients.

5.2.2 Command Chain Bypass.

5.2.3 Project-customized Hours.

5.2.4 Multi-lane Development Pathways.

5.2.5 Rethinking “Change Management”.

5.3 Limitations and Future Work

Footnotes

A Interview Questionnaire

A.1 Question 1

A.2 Question 2

A.3 Question 3

A.4 Question 4

A.5 Question 5

A.6 Question 6

B Prevalence of Themes

C Sample Code

References

Cited By

Index Terms

Recommendations

Employee Information Security Practices: A Framework and Research Agenda

Evaluation of requirement engineering best practices for secure software development in GSD: An ISM analysis

Security Practices in Agile Software Development: A Mapping Study

Comments

Information

Published In

Publisher

Publication History

Check for updates

Author Tags

Qualifiers

Contributors

Other Metrics

Bibliometrics

Article Metrics

Other Metrics

Citations

Cited By

View options

PDF

eReader

Login options

Full Access

Share

Share this Publication link

Share on social media

Affiliations